From 20e8b71bf627c57d33e4b0814bc73e50f659fddf Mon Sep 17 00:00:00 2001
From: Daniel Wohlgemuth <daniel.wohlgemuth.epp@gmail.com>
Date: Sun, 5 Sep 2021 12:25:35 -0400
Subject: [PATCH] Fix character encoding using iconv

---
 ...lular_automata_for_physical_modelling.html | 228 +++++++-------
 papers/gem_imp_filt.html                      |  60 ++--
 papers/gem_vipm_webversion.html               | 278 +++++++++---------
 papers/papers.html                            |   2 +-
 papers/trilight/trilight.html                 |  78 ++---
 5 files changed, 323 insertions(+), 323 deletions(-)

diff --git a/papers/cellular_automata_for_physical_modelling.html b/papers/cellular_automata_for_physical_modelling.html
index 844f107..bbe5d5b 100644
--- a/papers/cellular_automata_for_physical_modelling.html
+++ b/papers/cellular_automata_for_physical_modelling.html
@@ -67,8 +67,8 @@ <h1>Introduction</h1>
 </ul>
 
 <p>Some of these features are in some games, but only in
-heavily scripted and constrained ways – frequently they play little part in
-actual gameplay, and so can look rather artificial – which of course is exactly
+heavily scripted and constrained ways – frequently they play little part in
+actual gameplay, and so can look rather artificial – which of course is exactly
 what they are. Using Cellular Automata (CA) to simulate these ideas can lead to
 far more dynamic and realistic behaviour, and allow new types of gameplay and
 new tactics within games. At the very least, they allow more realism, better
@@ -94,9 +94,9 @@ <h1>CA Basics</h1>
 itself with its neighbouring cells. Differences between them result in changes
 to the state of the cell and/or its neighbours according to various laws. In
 this article, these will be based very loosely on real physical laws. One of
-the best-known CAs is “Conway’s Game of Life” [Conway ref]. This is an
-extremely simple CA – it has a single bit of state – whether the cell is full
-or not – and some extremely simple rules for changing state according to the
+the best-known CAs is “Conway’s Game of Life” [Conway ref]. This is an
+extremely simple CA – it has a single bit of state – whether the cell is full
+or not – and some extremely simple rules for changing state according to the
 state of neighbouring cells. Nevertheless, even this incredibly simple model is
 Turing-Machine-compatible [Conway Turing ref].</p>
 
@@ -108,7 +108,7 @@ <h1>CA Basics</h1>
 be heated by the burning objects.</p>
 
 <p>In a 3D array of cubic cells, there are three possible
-definitions of “neighbour” cells:</p>
+definitions of “neighbour” cells:</p>
 
 <ul>
 <li>The 6 cells that share a face with the central cell.</li>
@@ -126,7 +126,7 @@ <h1>CA Basics</h1>
 For human-sized games, we decided to use cubes that are half a metre across.
 Any bigger, and a CA cell of air will not fit inside a narrow passageway.
 Smaller cubes give higher resolution and allow smaller pipes, narrower gaps,
-and so on – but the extra space and processing is expensive. Different scales
+and so on – but the extra space and processing is expensive. Different scales
 of games will naturally require a different size of CA cell, but because most
 games are set at human scales, for convenience this article will assume a scale
 of half-metre cube cells in its examples.</p>
@@ -137,64 +137,64 @@ <h1>CA Basics</h1>
 smoke &amp; air spreading, so they must be modelled in some way. Modelling them
 conventionally by using many small cells, and marking those occupied by the
 wall as solid, would require using cells of no more than about ten centimetres
-across, which requires 125 times as many cells – an extremely expensive option.</p>
+across, which requires 125 times as many cells – an extremely expensive option.</p>
 
 <p>Two possible solutions present themselves. One method, used
 by the first in the X-Com series of games in their impressive and innovative
 use of CAs [X-Com ref], is to model the faces between the cells as entities, as
 well as the cells themselves. So walls, floors and ceilings always lie between
 two cells, along cell faces. This works quite well, but it does mean that there
-are now two distinct classes of object – things that fill a whole cube (rock,
+are now two distinct classes of object – things that fill a whole cube (rock,
 dirt, furniture, tall grass); and things that sit between two cells (walls,
 floorboards, short grass, doors). This creates annoying special cases in the
 code used to model substances and their interactions, and causes code
 replication between the two types, and debugging spaghetti. However, if this
-model fits, then it is a viable one, and it is fairly intuitive – the internal
+model fits, then it is a viable one, and it is fairly intuitive – the internal
 representation of objects matches their rendered shape fairly closely.</p>
 
 <p>The other solution is one that retains its generality
 without resorting to many tiny cells. This is far more flexible about where the
-visual “edges” of the cells are in the world. Rather than the concept of a
+visual “edges” of the cells are in the world. Rather than the concept of a
 fixed solid cubic cell, the edges between cells can move about a bit according
 to the contents. This allows a thin wall to be chopped into half-metre squares,
 and each square lives in a cell. Because the walls are only a few centimetres
 thick, neighbouring cells are thought of as expanding to make up the extra
-space. This “expansion” is simply a way of thinking about it – the CA code
+space. This “expansion” is simply a way of thinking about it – the CA code
 itself does not know or care what shape the objects it represents are. As far
 as the CA physics are concerned, everything is still half a metre thick. Most
 of the work in making things look otherwise is in the rendering, rather than in
 the CA routines. It is the job of the rendering to ensure that water goes all
-the way to the wall’s mesh, and not just the edge of the CA cube, which would
+the way to the wall’s mesh, and not just the edge of the CA cube, which would
 leave a large gap.</p>
 
 <p>In this scheme, a one-metre-wide corridor with thin wooden
-walls is represented by a plane of “wood” cells, a plane of “air” cells, and
-then a plane of “wood” cells. Since the centres of the cells are each half a
+walls is represented by a plane of “wood” cells, a plane of “air” cells, and
+then a plane of “wood” cells. Since the centres of the cells are each half a
 metre away from each other, the total width from wall to wall is still one
 metre. Of course, the graphical representation of the world still shows that
-the “cubes” of wood are not cubes at all but flat planes a few centimetres
+the “cubes” of wood are not cubes at all but flat planes a few centimetres
 thick, and this is the representation that will be used for any
 collision-detection, but the distinction makes very little difference to the
-things that are modelled with the CA – water, air, fire. Because these entities
+things that are modelled with the CA – water, air, fire. Because these entities
 are fairly amorphous, the difference between what is rendered and what is
 actually being modelled is very hard for the player to see. Again, accuracy is
 sacrificed for speed wherever the game can get away with it.</p>
 
-<p>The next factor to consider is a gameplay decision – the
+<p>The next factor to consider is a gameplay decision – the
 difference between using passive scenery and active scenery.</p>
 
 <h2>Passive Scenery</h2>
 
 <p>In this system, as far as the CA is concerned, the scenery
 is inert. Water will flow around scenery; fire, air and heat will be stopped by
-scenery. But the scenery is not affected by the actions of the CA in any way –
+scenery. But the scenery is not affected by the actions of the CA in any way –
 it does not burn, it does not get damaged, it does not get wet, or move in
 currents. This is the simpler of the two representations, but still allows
 discrete objects such as the ubiquitous oil drum and crate to float away on rivers
 of water, or to explode or burn when heated by fire.</p>
 
 <p>Because the CA only knows about cells, not polygons, the
-scenery must be converted into a cell representation – usually as a
+scenery must be converted into a cell representation – usually as a
 pre-processing step. These cells are simply marked as inert rock or similar,
 and their only function is to ensure that water cannot flow into them, and that
 heat is not exchanged with them. Of course, the scenery is usually a collection
@@ -213,23 +213,23 @@ <h2>Active Scenery</h2>
 
 <p>The far more versatile, though also more adventurous option,
 is to have the scenery modelled by the CA as well, and for fire, water and so
-on to affect bits of the scenery. This also opens up the “totally destructible
-world” concept that many are looking to as the next big thing in games, though
+on to affect bits of the scenery. This also opens up the “totally destructible
+world” concept that many are looking to as the next big thing in games, though
 as with everything, there is nothing truly new in computer games [XCom ref
 again].</p>
 
 <p>In this system, rather than simply being cells of inert
-material, scenery is modelled by its actual properties –current temperature,
+material, scenery is modelled by its actual properties –current temperature,
 how easily and fiercely it burns, how strong it is, and so on. As the cells of
 the CA change their state according to the physical rules of the CA, so the
-graphics engine changes how it renders the associated polygonal objects – they
+graphics engine changes how it renders the associated polygonal objects – they
 become sooty, damaged, glow red hot, or (if the graphics engine can handle it)
 they vanish altogether.</p>
 
 <p>In the latter case, the graphics engine can either be of the
-“Geo-Mod” type [Red Faction ref], or the object itself can simply have been
+“Geo-Mod” type [Red Faction ref], or the object itself can simply have been
 specially marked as destructible, such as a thin wooden wall, and have an
-alternative “broken” representation, as done by current engines when dealing
+alternative “broken” representation, as done by current engines when dealing
 with damage by weapon fire.</p>
 
 <h1>The Octree</h1>
@@ -238,17 +238,17 @@ <h1>The Octree</h1>
 quickly noticed that storing half-metre cells for even a modestly-sized level
 consumes a huge amount of memory, and the processing and memory-bandwidth
 requirements become severe. The trick is to not store or process cells that are
-not participating in any interesting activities – notably inert walls, and air
-at ambient or “standard” temperature and pressure (STP).</p>
+not participating in any interesting activities – notably inert walls, and air
+at ambient or “standard” temperature and pressure (STP).</p>
 
 <p>An octree is ideally suited to storing this arrangement,
 specifically a dynamically-allocated octree. In any implementation of the
-octree, remember that by far the most common operation in a CA is “find the
-cell next to this one”, so optimising for this type of operation when
+octree, remember that by far the most common operation in a CA is “find the
+cell next to this one”, so optimising for this type of operation when
 implementing the octree will pay off in terms of speed. If this request is
 made, and there is no neighbouring cell in the octree, it is assumed that the
 neighbouring cell is air at standard temperature and pressure. The physical
-simulations are carried out accordingly, and if they result in the “missing”
+simulations are carried out accordingly, and if they result in the “missing”
 cell becoming significantly different from standard temperature and pressure, a
 cell with the new properties is created and inserted in the octree. When an air
 cell returns to within a certain tolerance of standard temperature and
@@ -258,8 +258,8 @@ <h1>The Octree</h1>
 octree. Many games use octrees to optimise collision detection and culling when
 rendering (e.g. frustum culling), and there is no reason this one cannot fulfil
 both roles, and hold objects not directly related to the CA. A fairly easy
-adaptation to the search algorithms allows the octree to become a “loose
-octree,” [ref Thatcher Ulrich] which has several other advantages over a
+adaptation to the search algorithms allows the octree to become a “loose
+octree,” [ref Thatcher Ulrich] which has several other advantages over a
 conventional octree. This does not change its behaviour when dealing with the
 CA aspect of its behaviour, since all CA cells are aligned to regular intervals
 and have a fixed size.</p>
@@ -296,15 +296,15 @@ <h1>Core Processing Model</h1>
 <pre>
 for ( neigh = each neighbour cell )
 {
-    if ( neigh-&gt;Material-&gt;IsInert() )
+    if ( neigh-&gt;Material-&gt;IsInert() )
     {
         continue;
     }
-    float DPress = cell-&gt;Pressure – neigh-&gt;Pressure;
-    float Flow = cell-&gt;Material-&gt;Flow * DPress;
-    Flow = clamp ( Flow, cell-&gt;Pressure / 6.0f, -neigh-&gt;Pressure / 6.0f );
-    cell-&gt;NewPressure -= Flow;
-    neigh-&gt;NewPressure += Flow;
+    float DPress = cell-&gt;Pressure – neigh-&gt;Pressure;
+    float Flow = cell-&gt;Material-&gt;Flow * DPress;
+    Flow = clamp ( Flow, cell-&gt;Pressure / 6.0f, -neigh-&gt;Pressure / 6.0f );
+    cell-&gt;NewPressure -= Flow;
+    neigh-&gt;NewPressure += Flow;
 }
 </pre>
 
@@ -334,21 +334,21 @@ <h1>Core Processing Model</h1>
 <pre>
 if ( cell-&gt;Turn != CurrentTurn )
 {
-    cell-&gt;Turn = CurrentTurn;
-    cell-&gt;Pressure = cell-&gt;NewPressure;
+    cell-&gt;Turn = CurrentTurn;
+    cell-&gt;Pressure = cell-&gt;NewPressure;
 }
 for ( neigh = each neighbour cell )
 {
-    if ( neigh-&gt;Material-&gt;IsInert() )
+    if ( neigh-&gt;Material-&gt;IsInert() )
     {
         continue;
     }
-    if ( neigh-&gt;Turn != CurrentTurn )
-    {
-        neigh-&gt;Turn = CurrentTurn;
-        neigh-&gt;Pressure = neigh-&gt;NewPressure;
-    }
-    // ... same physics code as before ...
+    if ( neigh-&gt;Turn != CurrentTurn )
+    {
+        neigh-&gt;Turn = CurrentTurn;
+        neigh-&gt;Pressure = neigh-&gt;NewPressure;
+    }
+    // ... same physics code as before ...
 }
 </pre>
 
@@ -356,13 +356,13 @@ <h1>Air</h1>
 
 <p>The above simple model works well for uniform redistribution
 of air pressure. At first glance, this is not something that is frequently
-modelled in games, but in fact it is one of the commonest effects – explosions,
+modelled in games, but in fact it is one of the commonest effects – explosions,
 and their effects on things. An explosive is simply a lump of material that
 produces a huge amount of air in a very short time. They can be modelled by
 finding the nearest CA cell to the centre of an exploding grenade, and adding a
-large number to the cell’s pressure, then letting the CA propagate the pressure
+large number to the cell’s pressure, then letting the CA propagate the pressure
 through the world. Damage is done to the surroundings by either high absolute
-pressures or high pressure differences – in reality both do different sorts of
+pressures or high pressure differences – in reality both do different sorts of
 damage to different objects, but that is usually unnecessary complication for
 the purposes of a game.</p>
 
@@ -370,7 +370,7 @@ <h1>Air</h1>
 ones is that line-of-sight modelling is handled automatically. Explosions in
 confined spaces are far more deadly at a certain range than explosions in open
 spaces, because there is less space for the pressure to dissipate. In addition,
-it shows that pure line-of-sight is not protection enough from explosions –
+it shows that pure line-of-sight is not protection enough from explosions –
 they do go around corners and obstructions to a certain degree.</p>
 
 <p>Because the simulation of the flow of air is qualitatively
@@ -388,47 +388,47 @@ <h1>Water</h1>
 <p>In fact, the easiest way to simulate the transmission of
 pressure through water is to make it slightly compressible. This means pressure
 can be stored as a slight excess mass of water in the cell, above what the
-cell’s volume should be able to hold. In practice, the amount of compression
-needed is tiny – allowing just 1% more water per cell per cube height is easily
+cell’s volume should be able to hold. In practice, the amount of compression
+needed is tiny – allowing just 1% more water per cell per cube height is easily
 enough. In a static body of water whose cells can normally contain one litre of
 water each, the cells at the top will contain one litre, the ones under them
 will contain 1.01 litres, the cells under those will contain 1.02 litres, and
 so on to the bottom. This tiny amount of compression will be completely unnoticeable
 to the player, but has enough dynamic range to allow all the usual properties
 of liquids. For example, the levels of water in two containers joined by a
-submerged pipe will be the same, even if water is poured into one of them – it
+submerged pipe will be the same, even if water is poured into one of them – it
 will flow through the pipe to the other container.</p>
 
 <pre>
 if ( neighbour cell is above this one )
 {
-    if ( ( cell-&gt;Mass &lt; material-&gt;MaxMass ) ||
-         ( neigh-&gt;Mass &lt; material-&gt;MaxMass ) )
-    {
-        Flow = cell-&gt;Mass - material-&gt;MaxMass;
-    }
+    if ( ( cell-&gt;Mass &lt; material-&gt;MaxMass ) ||
+         ( neigh-&gt;Mass &lt; material-&gt;MaxMass ) )
+    {
+        Flow = cell-&gt;Mass - material-&gt;MaxMass;
+    }
     else
     {
-        Flow = cell-&gt;Mass – neigh-&gt;Mass - material-&gt;MaxCompress;
-        Flow *= 0.5f;
+        Flow = cell-&gt;Mass – neigh-&gt;Mass - material-&gt;MaxCompress;
+        Flow *= 0.5f;
     }
 }
 else if ( neighbour cell is below this one )
 {
-    if ( ( cell-&gt;Mass &lt; material-&gt;MaxMass ) ||
-         ( neigh-&gt;Mass &lt; material-&gt;MaxMass ) )
-    {
-        Flow = material-&gt;MaxMass - neigh-&gt;Mass;
-    }
+    if ( ( cell-&gt;Mass &lt; material-&gt;MaxMass ) ||
+         ( neigh-&gt;Mass &lt; material-&gt;MaxMass ) )
+    {
+        Flow = material-&gt;MaxMass - neigh-&gt;Mass;
+    }
     else
     {
-        Flow = cell-&gt;Mass – neigh-&gt;Mass + material-&gt;MaxCompress;
-        Flow *= 0.5f; 
-    }
+        Flow = cell-&gt;Mass – neigh-&gt;Mass + material-&gt;MaxCompress;
+        Flow *= 0.5f; 
+    }
 }
 else // neighbour is on same level
 {
-    Flow = ( cell-&gt;Mass – neigh-&gt;Mass ) * 0.5f;
+    Flow = ( cell-&gt;Mass – neigh-&gt;Mass ) * 0.5f;
 }
 </pre>
 
@@ -439,24 +439,24 @@ <h1>Water</h1>
 
 <p>The two cases of code for both the up and the down case deal
 with different situations. The first case is where one of the two cells is not
-full of water – on the surface of a body of water, or if the water is splashing
-or falling (for example, in a waterfall). Here, the behaviour is simple – water
-flows downwards to fill the lower cell of the two to the value MaxMass – this
-is the mass of water that can be contained by a single cell’s volume. In the
+full of water – on the surface of a body of water, or if the water is splashing
+or falling (for example, in a waterfall). Here, the behaviour is simple – water
+flows downwards to fill the lower cell of the two to the value MaxMass – this
+is the mass of water that can be contained by a single cell’s volume. In the
 example above, the mass of 1 litre of water.</p>
 
 <p>The second case is where both cells are full of water, or
 perhaps a bit over-full. This is an area of water that is at pressure, and are
 cells in the middle of a body of water. Here, the flow acts to try to make sure
 that the upper cell has exactly MaxCompress more water than the lower cell.
-MaxCompress is the amount of “extra” water that can be fitted in because of
-compression – in the example above, it would be the mass of 0.01 litres of
+MaxCompress is the amount of “extra” water that can be fitted in because of
+compression – in the example above, it would be the mass of 0.01 litres of
 water.</p>
 
 <h1>Flow</h1>
 
 <p>So far the air and water models have ignored a fairly
-important property of any liquid or gas – its speed of flow. It has  simply
+important property of any liquid or gas – its speed of flow. It has  simply
 taken the difference in pressures between two cells, and used that to move mass
 around. This is fine for relatively static environments that we wish to bring
 to a stable state (uniform air pressure, or water finding its level). Many
@@ -479,7 +479,7 @@ <h1>Flow</h1>
 
 <p>There are two possible ways to think about flow. The first
 is to think of a flow vector as being the flow through the centre of the cell.
-This is possibly the most intuitive model – the flow and the mass of the cell
+This is possibly the most intuitive model – the flow and the mass of the cell
 are both measured at its centre. However, in this case, the flow is affected by
 the pressure differential between the two neighbouring cells, and in turn
 determines how mass flows from one neighbouring cell to the other. Note the
@@ -489,11 +489,11 @@ <h1>Flow</h1>
 surprising result, and in some cases can lead to some odd behaviour.</p>
 
 <p>The more useful model is to think of each component of the
-flow vector as being the flow between two adjacent nodes – from the “current”
+flow vector as being the flow between two adjacent nodes – from the “current”
 node to the node in the positive relevant direction. Thus the flow vector F
 stored at cell (x,y,z) has the meaning that F.x is the flow from cell (x,y,z)
 to cell (x+1,y,z); F.y is the flow from cell (x,y,z) to cell (x,y+1,z); and
-similarly for F.z. The “meaning” of the vector F is now not as intuitive, but
+similarly for F.z. The “meaning” of the vector F is now not as intuitive, but
 the physical model does seem more sensible. In practice, this is the most
 common model, but either model can be used for simulation with appropriate
 adjustment of the various constants.</p>
@@ -505,12 +505,12 @@ <h1>Flow</h1>
 dying down, and the liquid or gas starts to do very odd things indeed.</p>
 
 <p>It is worth mentioning that although one of the most common
-applications of flow is in rivers, in most “human-sized” games, large bodies of
+applications of flow is in rivers, in most “human-sized” games, large bodies of
 water such as lakes and rivers are frequently far too large to participate in
 gameplay. Their behaviour will stay fairly constant whatever the player does,
 and if they do change, they will do so in highly constrained ways. They do not
 usually require the flexibility of a CA, and are often far better modelled and
-rendered in more conventional ways – pre-animated meshes and collision models,
+rendered in more conventional ways – pre-animated meshes and collision models,
 and scripted events. However, there are many other genres that operate on
 larger scales and will want to properly simulate rivers with a CA.</p>
 
@@ -518,21 +518,21 @@ <h1>Heat</h1>
 
 <p>Transmitting heat through the environment, whether from
 burning objects or from other sources, happens through three separate
-mechanisms – conduction, convection and radiation.</p>
+mechanisms – conduction, convection and radiation.</p>
 
 <h2>Conduction</h2>
 
 <p>Conduction is the simplest to simulate. Neighbouring cells
 pass heat energy between each other so that eventually they reach the same
 temperature as each other. This is complicated because different materials are
-heated by different amounts by the same amount of energy – called the Specific
-Heat Capacity (SHC – usually measured in J/kg°C).
+heated by different amounts by the same amount of energy – called the Specific
+Heat Capacity (SHC – usually measured in J/kg°C).
 If a hot cell made of water (high SHC, hard to heat up) is next to a colder
 cell made of the same mass of iron (low SHC), equilibrium will be reached at
 somewhere very close to the original temperature of the water, not at the
 average of the two temperatures. This is because when a given amount of energy
-is transferred from the water to the iron, the water’s temperature drops far
-less than the iron’s temperature rises.</p>
+is transferred from the water to the iron, the water’s temperature drops far
+less than the iron’s temperature rises.</p>
 
 <p>Note that the above example is true for the same <i>mass</i>
 of each substance. However, iron has a far greater density than water, and
@@ -546,11 +546,11 @@ <h2>Conduction</h2>
 // Convert from heat to energy
 if ( EnergyFlow &gt; 0.0f )
 {
-    EnergyFlow *= HCNeigh;
+    EnergyFlow *= HCNeigh;
 }
 else
 {
-    EnergyFlow *= HCCell;
+    EnergyFlow *= HCCell;
 }
 
 // A constant according to cell update speed.
@@ -561,24 +561,24 @@ <h2>Conduction</h2>
 
 // Detect and kill oscillations.
 if (((EnergyFlow&gt;0.0f)&amp;&amp;(neigh-&gt;Temp&lt;cell-&gt;Temp))||
-    ((EnergyFlow&lt;=0.0f)&amp;&amp;(neigh-&gt;Temp&gt;cell-&gt;Temp)))
+    ((EnergyFlow&lt;=0.0f)&amp;&amp;(neigh-&gt;Temp&gt;cell-&gt;Temp)))
 {
-    float TotalEnergy = HCCell * cell-&gt;Temp +
-                        HCNeigh * neigh-&gt;Temp;
-    float AverageTemp = TotalEnergy / ( HCCell + HCNeigh );
-    cell-&gt;Temp = AverageTemp;
+    float TotalEnergy = HCCell * cell-&gt;Temp +
+                        HCNeigh * neigh-&gt;Temp;
+    float AverageTemp = TotalEnergy / ( HCCell + HCNeigh );
+    cell-&gt;Temp = AverageTemp;
     neigh-&gt;Temp = AverageTemp;
 }
 </pre>
 
 <p>The code at the end is necessary if two materials with very
-different SHCs are side by side – the temperatures of the two can oscillate
+different SHCs are side by side – the temperatures of the two can oscillate
 violently, and can grow out of control. The physically correct solution is to
 integrate the transfer of heat over time. However, this approach simply finds
 the weighted average temperature (i.e. the temperature that the system would
 reach eventually). It is less accurate, but looks perfectly good to the eye,
 and is quite a bit quicker to execute. Importantly, it obeys the conservation
-of energy, so any artefacts are purely temporary – the longer-term state is the
+of energy, so any artefacts are purely temporary – the longer-term state is the
 same as a more realistic simulation.</p>
 
 <h2>Convection</h2>
@@ -593,7 +593,7 @@ <h2>Convection</h2>
 
 <h2>Radiation</h2>
 
-<p>Hot things glow – they emit light at various wavelengths
+<p>Hot things glow – they emit light at various wavelengths
 which travels in straight lines, hits other surfaces, and in turn heats them
 up. This effect is very important physically, but unfortunately is also
 extremely expensive to model. Each source of heat must effectively shoot many
@@ -607,7 +607,7 @@ <h2>Radiation</h2>
 fraction of the radiative heat seems like a prohibitive amount of work for a
 game. These algorithms are also extremely complex, and do not involve the
 standard cell-to-cell interactions that model all the other physical properties
-mentioned – for both these reasons, they are well beyond the scope of this Gem.
+mentioned – for both these reasons, they are well beyond the scope of this Gem.
 The application of radiation to fire is discussed further below.</p>
 
 <h1>Fire</h1>
@@ -634,7 +634,7 @@ <h1>Fire</h1>
 
 
 <pre>
-float Temp = cell-&gt;Temp – material-&gt;Flashpoint;
+float Temp = cell-&gt;Temp – material-&gt;Flashpoint;
 if ( Temp < 0.0f )
 {
     // Not burning.
@@ -672,7 +672,7 @@ <h1>Fire</h1>
 methods discussed above. In real-life fires, convection and radiation are
 incredibly important for their behaviour. Convection makes fires spread
 vertically far easier than spreading across floors, and leads to distinctive
-“walls of fire” in burning buildings. Radiation concentrates fire in corners of
+“walls of fire” in burning buildings. Radiation concentrates fire in corners of
 rooms, causing fire to spread up the corners of room first.</p>
 
 <p>Sadly, radiative heat, as mentioned above, is extremely hard
@@ -687,7 +687,7 @@ <h1>Fire</h1>
 wall heats the air beside it, which rises, heats the section of wall higher up,
 which makes it far easier for the flames to spread upwards. In
 this hack, conduction of heat is made artificially asymmetrical. In the model
-presented above, a single factor – ConstantEnergyFlowFactor – was 
+presented above, a single factor – ConstantEnergyFlowFactor – was 
 used for heat conduction for all six neighbors of a cell.
 Instead of this, a higher figure is used when conducting heat upwards,
 and a lower figure when conducting heat downwards.</p>
@@ -697,7 +697,7 @@ <h1>Fire</h1>
 which parts of a room would be more susceptible to fire because of the feedback
 effects of radiative heat. One possibility is computing the ambient
 occlusion term [Ambient ref] and using that to boost the heat generated
-by fire – generally around the edges and corners.</p>
+by fire – generally around the edges and corners.</p>
 
 <p>A factor that may not be immediately obvious is that these
 hacks are far more controllable than any realistic solution. Convection in real
@@ -714,15 +714,15 @@ <h1>Dynamic Update Rates</h1>
 <p>The nature of some of the physical properties being
 simulated here require high update rates to maintain realism. The flow of any
 property from one cell to another can only proceed at a maximum speed of one
-cell per update cycle. Fire may spread quickly – metres per second or faster.
-Water spilling from a container may move faster – tens of metres per second.
-Explosions require extremely high update rates – real-life explosion shock
-waves spread at the speed of sound – roughly 340m/s.</p>
+cell per update cycle. Fire may spread quickly – metres per second or faster.
+Water spilling from a container may move faster – tens of metres per second.
+Explosions require extremely high update rates – real-life explosion shock
+waves spread at the speed of sound – roughly 340m/s.</p>
 
 <p>Simulating all the above implies that update rates of 680
 cycles per second may be required. This is an awesome speed, and it seems
 unlikely any current platform can sustain these sorts of update rates for a
-decently-sized game world – the number of cells to update per second is
+decently-sized game world – the number of cells to update per second is
 enormous.</p>
 
 <p>As with the optimisation of not storing or processing cells
@@ -750,8 +750,8 @@ <h1>Dynamic Update Rates</h1>
 For example, if a child node needs to be updated every third turn, but the
 parent node is marked as being updated every second turn, every sixth turn the
 child node needs updating, but the parent does not. Because of the traversal
-algorithm’s early-out path, the child does not get updated this time, and in
-the end only gets updated every sixth turn – half the required frequency.
+algorithm’s early-out path, the child does not get updated this time, and in
+the end only gets updated every sixth turn – half the required frequency.
 Quantising update rates to powers of two solves this problem, and also allows
 some slight extra efficiency by storing the update rates as the power, rather
 than the actual number.</p>
@@ -765,7 +765,7 @@ <h1>Dynamic Update Rates</h1>
 the variable update rate is to choose an update rate to ensure that cells have
 fairly constant behaviour over the update interval.</p>
 
-<p>This assumption makes integration rather simple – simply
+<p>This assumption makes integration rather simple – simply
 multiply the given behaviour (water flow, heat flow, burn rate, etc) by the
 time period since the last update. This slight extra complication is more than
 offset by the savings in processing time and memory bandwidth from the huge
@@ -808,13 +808,13 @@ <h1>References</h1>
 
 <p>[Conway Turing ref] An "implementation" of a Turning Machine within Conway's Game of Life, written by Paul Rendell. The original site has vanished off the web, but Archive.org still has a copy here: <a href="http://web.archive.org/web/20030210114324/http://www.rendell.uk.co/gol/tm.htm">http://web.archive.org/web/20030210114324/http://www.rendell.uk.co/gol/tm.htm</a></p>
 
-<p>[XCom ref] “X-Com: UFO Defense”(US)/”UFO: Enemy Unknown”(UK)
+<p>[XCom ref] “X-Com: UFO Defense”(US)/“UFO: Enemy Unknown”(UK)
 Microprose, 1994 (<a href="http://www.lasersquadnemesis.com/AboutUs.htm">Codo games</a>, <a href="http://www.mobygames.com/game/dos/x-com-ufo-defense">Mobygames</a> and <a href="http://en.wikipedia.org/wiki/Xcom">Wikipedia</a>)</p>
 
-<p>[Red Faction ref] “Red Faction”, developed by Volition Inc,
+<p>[Red Faction ref] “Red Faction”, developed by Volition Inc,
 published by THQ Inc, 2000 (<a href="http://www.mobygames.com/game/windows/red-faction">Mobygames</a>). It should be noted that as far as I know, Red Faction did not use the sort of voxelised representation discussed here. My belief (from experimentation) is that it created a BSP representation of the scenery, and as the various "geomod" weapons and abilities were used, they inserted planes and nodes into the BSP. However, it is a good example of a game that takes the idea of "everything is destructible" and makes it a core gameplay feature.</p>
 
-<p>[Thatcher Ulrich ref] “Loose Octrees”, Thatcher Ulrich, Game
+<p>[Thatcher Ulrich ref] “Loose Octrees”, Thatcher Ulrich, Game
 Programming Gems, Charles River Media, 2000 (<a href="http://tulrich.com/geekstuff/">http://tulrich.com/geekstuff/</a>)</p>
 
 <p>[Ambient ref] Ambient occlusion turns out to be the DC component of the elegantly general Spherical Harmonic representation. A good introduction to SH for the games programmer is a presentation I did in 2003 called <a href="http://www.eelpi.gotdns.org/papers/papers.html">Spherical Harmonics in Actual Games</a>.</p>
diff --git a/papers/gem_imp_filt.html b/papers/gem_imp_filt.html
index 8937812..fbfc0a6 100644
--- a/papers/gem_imp_filt.html
+++ b/papers/gem_imp_filt.html
@@ -1,6 +1,6 @@
 <html>
 	<head>
-		<title>Impostors – Adding Clutter</title>
+		<title>Impostors – Adding Clutter</title>
 		<style>
 			<!--
  /* Style Definitions */
@@ -11,20 +11,20 @@
 --></style>
 	</head>
 	<body lang="EN-GB" link="blue" vlink="#606420">
-		<p class="MsoTitle">Impostors – Adding Clutter</p>
-		<h1>Impos…what?</h1>
+		<p class="MsoTitle">Impostors – Adding Clutter</p>
+		<h1>Impos…what?</h1>
 		<p>Impostoring is a term that is probably not familiar to many reading this. 
-			However, the concept may be – it has surfaced in various forms many times in 
+			However, the concept may be – it has surfaced in various forms many times in 
 			the history of 3D graphics. Simply put, it is about using sprites in a 3D 
 			scene, but instead of an artist drawing or rendering the sprites beforehand, 
 			they are updated on the fly by rendering triangles to them.</p>
 		<p>Instead of rendering a high-triangle object every frame, the high-triangle 
-			object is rendered to a texture only occasionally – usually on the order of 
+			object is rendered to a texture only occasionally – usually on the order of 
 			once every five to fifty frames. But every frame this texture is mapped onto a 
 			much lower-triangle object and drawn.</p>
 		<p>The main target for impostors is scenes with lots of small static objects in 
-			them – clutter. Each of these objects will use an impostor, and most will be 
-			redrawn at a much lower rate than the main scene’s frame rate. By doing this, 
+			them – clutter. Each of these objects will use an impostor, and most will be 
+			redrawn at a much lower rate than the main scene’s frame rate. By doing this, 
 			the perceived triangle density is far higher than the actual one, and the 
 			visual quality allowed by all these incidental objects considerably increases 
 			the realism of the scene. The main difference between an office or house in a 
@@ -34,13 +34,13 @@
 			usually a bottleneck, and reducing this for some objects allows greater 
 			triangle detail to be used on others. An impostor is a single texture, whereas 
 			rendering the object normally may require multiple textures and multiple 
-			texture layers – changing texture flushes the texture cache and may require 
+			texture layers – changing texture flushes the texture cache and may require 
 			extra texture management from either the driver, the API, or the application. 
 			Drawing the object each frame requires that it be lit each frame, even if the 
 			lighting has not changed, and as lighting techniques become more sophisticated, 
 			lighting becomes more expensive. And finally there is usually plenty of 
 			application overhead when just thinking about drawing an object, even before a 
-			single API call is made – using impostors can avoid much of that work.</p>
+			single API call is made – using impostors can avoid much of that work.</p>
 		<h1>The Whole Process</h1>
 		<ul>
 			<li>
@@ -49,7 +49,7 @@ <h1>The Whole Process</h1>
 				Rendering the impostor texture on the screen each frame. I call this 
 				&quot;rendering&quot; the impostor.</li>
 			<li>
-				Rendering the impostor’s mesh at low speeds to the texture. I call this 
+				Rendering the impostor’s mesh at low speeds to the texture. I call this 
 				&quot;updating&quot; the impostor.</li>
 			<li>
 				Deciding when to update the impostor, and when to leave it.</li>
@@ -100,7 +100,7 @@ <h2>ONE:INVSRCALPHA</h2>
 			intended, because the impostor has only a single alpha channel to express the 
 			amount of background to allow through. Fortunately, these sorts of effects are 
 			rarely used on objects that are suitable for impostoring. Note this only 
-			applies to actual translucent effects – opaque multi-pass rendering that uses 
+			applies to actual translucent effects – opaque multi-pass rendering that uses 
 			alpha-blending to combine the passes (e.g. light maps, detail maps, etc) will 
 			be fine, as long as the final alpha-channel value is carefully controlled.</p>
 		<h2>Billboard Quad</h2>
@@ -127,7 +127,7 @@ <h2>Cuboid</h2>
 			bounding box of the object is drawn, with the impostor texture projected on it. 
 			Because the bounding box is a real 3D object, its Z-buffer properties can be 
 			controlled far better than a screen-aligned quad. In particular, its Z-buffer 
-			properties are now independent of the camera position – they only depend on the 
+			properties are now independent of the camera position – they only depend on the 
 			object position and orientation, which is one less thing the app has to worry 
 			about.</p>
 		<p>Bounding boxes actually work quite well. Most things in everyday life fill their 
@@ -143,7 +143,7 @@ <h2>Cuboid</h2>
 		<h2>Bounding Object</h2>
 		<p>There are plenty of objects for which a bounding box is not a good enough 
 			approximation, and leads to unnecessary Z-buffer clashes. There is also another 
-			factor to consider in choosing the shape of the impostor – parallax error. The 
+			factor to consider in choosing the shape of the impostor – parallax error. The 
 			whole point of a 3D scene is that a camera can move through it, even if the 
 			objects in the scene are stationary. A box painted with a picture of something 
 			on it is not going to look like that something for long when the camera starts 
@@ -167,13 +167,13 @@ <h2>Image Warping</h2>
 			is bound to be larger than the image it represents. Using a higher-tri impostor 
 			object can help reduce this in the case of entirely convex source objects. 
 			However, for non-convex source objects, this does not noticeably improve 
-			matters – the impostor object must remain convex, and no amount of tris will 
+			matters – the impostor object must remain convex, and no amount of tris will 
 			allow it to match a concave object.</p>
 		<p>Another way to deal with this is to move the texture co-ordinates at each vertex 
 			each frame. The tri counts involved are fairly low, so a bit more work at each 
-			vertex is unlikely to hurt performance much. The principle is fairly simple – 
+			vertex is unlikely to hurt performance much. The principle is fairly simple – 
 			figure out where on the real object (and thus the impostor texture image) each 
-			impostor object’s vertex lies when viewed from a certain angle. As this viewing 
+			impostor object’s vertex lies when viewed from a certain angle. As this viewing 
 			angle changes, the texel that the vertex lies over will change. So for a new 
 			viewing angle, trace the line from the viewer through the impostor object 
 			vertex to the original object. Then work out which texel this part of the 
@@ -185,14 +185,14 @@ <h2>Nice Theory, What Can We Get Away With?</h2>
 			&quot;chasm&quot; in the object and, because of the low density of vertices in 
 			the impostor object, producing large warps over the image. Another problem is 
 			what to do with vertices at the edge of the impostor object that do not map to 
-			any part of the real object at all – what happens to them? Some sort of 
+			any part of the real object at all – what happens to them? Some sort of 
 			interpolation seems to be needed from the visible edges of the object, out to 
 			these vertices. This is the sort of work that an app does not want to be doing 
 			at runtime, however few vertices it involves.</p>
 		<p>In practice what I have found to be far simpler, and works just fine, is to give 
-			each vertex a &quot;parallax factor&quot; – the number of image texels to move 
+			each vertex a &quot;parallax factor&quot; – the number of image texels to move 
 			per degree of viewer movement. This is a factor usually tweaked by hand, and 
-			easily determines the vertex’s texel co-ordinates at runtime. This factor is 
+			easily determines the vertex’s texel co-ordinates at runtime. This factor is 
 			only done once for each impostor object vertex, and hand-tweaking around eight 
 			to ten vertices per object does not take long.</p>
 		<p>Alternatively, to generate these parallax values automatically for moderately 
@@ -249,8 +249,8 @@ <h2>Viewing Angle</h2>
 		<p>Changing the viewing angle is probably the most obvious factor that decides an 
 			impostor update. Note that what is important is the vector from the camera to 
 			the object in object space. This will change when the object rotates, and also 
-			when the camera moves, both of which are important. The camera’s direction of 
-			view is unimportant – unless an enormous field of view is used, the object does 
+			when the camera moves, both of which are important. The camera’s direction of 
+			view is unimportant – unless an enormous field of view is used, the object does 
 			not change appearance much when the camera rotates, only when it moves.</p>
 		<h2>Camera Distance</h2>
 		<p>As well as the direction from the object to the camera, the distance between the 
@@ -271,7 +271,7 @@ <h2>Game-Specific Heuristics</h2>
 			&quot;important&quot; objects. Items that are purely in the scene to create an 
 			ambience, but are not usually involved in the gameplay can be assigned a 
 			relatively large screen error. The player will not be examining them terribly 
-			closely – their attention is likely to be elsewhere. So these objects can be 
+			closely – their attention is likely to be elsewhere. So these objects can be 
 			more wrong before the player notices the error.</p>
 		<h1>Efficiency</h1>
 		<p>The main efficiency hit on most cards is changing rendertarget. This causes 
@@ -290,9 +290,9 @@ <h1>Efficiency</h1>
 		<p>When allocating a block of a certain size, it should be allocated as far down 
 			the quadtree as possible, i.e. in a node that is the correct size. If no node 
 			is the correct size, the smallest possible node should be split up to create 
-			it. This again prevents larger blocks being split up unnecessarily – they may 
-			be used later by a large impostor. Although this sounds expensive – having to 
-			scan the whole quadtree for the smallest node – in practice a lot of caching 
+			it. This again prevents larger blocks being split up unnecessarily – they may 
+			be used later by a large impostor. Although this sounds expensive – having to 
+			scan the whole quadtree for the smallest node – in practice a lot of caching 
 			can be done, and it does not take a significant amount of time.</p>
 		<h1>Prediction</h1>
 		<p>When updating an impostor, the current state of the object is rendered to the 
@@ -312,17 +312,17 @@ <h1>Prediction</h1>
 			in the first place. It should be reasonably simple to add some useful forward 
 			prediction onto games such as this.</p>
 		<p>However, with games such as first-person-shooters, objects in the world are 
-			basically split into two distinct categories – those that almost never move 
+			basically split into two distinct categories – those that almost never move 
 			(walls, furniture, clutter), and those that move erratically (players). The 
 			movement of the players is notoriously hard to predict, and it is probably a 
 			waste of time trying to impostor players.</p>
 		<p>On the other hand, impostoring the scenery and furniture is a far more viable 
-			proposition. Prediction for them is trivial – they almost never move. And when 
+			proposition. Prediction for them is trivial – they almost never move. And when 
 			they do move, they usually move under control of a player, i.e. erratically. 
 			The easiest thing is to simply disable impostoring for the duration of the 
 			movement.</p>
 		<p>For god games and Real Time Strategy (RTS) games, the problems are similar, but 
-			the movement of the camera is very different. It is usually a bird’s-eye view, 
+			the movement of the camera is very different. It is usually a bird’s-eye view, 
 			and most of the time it is either static (while issuing orders to units), or 
 			moving at constant speed over the map to get to a different area. Small, 
 			erratic movements are rare, which is fortunate since these are extremely hard 
@@ -336,14 +336,14 @@ <h1>Summary</h1>
 		<p>Impostoring is useful when trying to draw scenes with lots of fairly static 
 			objects in them. The raw triangle count will overwhelm any bus and graphics 
 			device that tries to render them at top detail, and progressive mesh methods 
-			can only do a certain amount to reduce the workload – texture changes and 
+			can only do a certain amount to reduce the workload – texture changes and 
 			animation are extremely difficult to reduce in this way.</p>
 		<p>Impostoring is most effective on static objects some distance from the camera. 
 			Introducing this sort of clutter into games increases the visual quality 
 			substantially, especially since each object is still a real independent 3D 
 			object and can still be interacted with by the player. It also allows key 
 			objects to be &quot;hidden in plain sight&quot; amongst a lot of other objects 
-			– something that has been extremely difficult to do with existing techniques 
+			– something that has been extremely difficult to do with existing techniques 
 			and the limited number of objects available in a scene.</p>
 		<p>Even an implementation using a bounding box and some simple maths produces good 
 			results for the incidental objects that are currently missing from games, but 
diff --git a/papers/gem_vipm_webversion.html b/papers/gem_vipm_webversion.html
index 97a9ee7..647458c 100644
--- a/papers/gem_vipm_webversion.html
+++ b/papers/gem_vipm_webversion.html
@@ -94,9 +94,9 @@ <h1>Introduction</h1>
 <p class=MsoNormal>This Gem does assume a basic familiarity
 with VIPM, and there is no space for a thorough introduction here. However,
 there are several good guides both in print and online. The two best known are
-Jan Svarovsky’s Gem in Game Programming Gems 1 [Svarovsky00] and Charles
-Blooms’ website [Bloom01], both of which have excellent step-by-step guides to
-implementations of the “vanilla” VIPM method. All the methods discussed here
+Jan Svarovsky’s Gem in Game Programming Gems 1 [Svarovsky00] and Charles
+Blooms’ website [Bloom01], both of which have excellent step-by-step guides to
+implementations of the “vanilla” VIPM method. All the methods discussed here
 use the same basic collapse/split algorithm, but implement it in different
 ways.</p>
 
@@ -142,7 +142,7 @@ <h1>Considerations</h1>
 graphics card. On a PC, this means the AGP bus bandwidth.</li>
 
 <li>
-Vertex–cache coherency. Modern graphics cards
+Vertex–cache coherency. Modern graphics cards
 try to fetch, transform and light each vertex only once, even though the vertex
 will be used by multiple triangles. To do this they have a vertex cache that
 holds the most recently used vertices, and applications need to try to use
@@ -155,13 +155,13 @@ <h1>Considerations</h1>
 
 <p class=MsoNormal>Vertex cache coherency will be quoted in
 terms of the number of vertices loaded or processed per triangle drawn, or
-“vertices per triangle”. Current triangle reordering algorithms for static
+“vertices per triangle”. Current triangle reordering algorithms for static
 (i.e. non-VIPM) meshes, using modern vertex caches of around 16 entries can get
 numbers down to around 0.65. For an example, see [Hoppe99]. This gives suitable
 benchmark figures to compare efficiencies when the mesh is converted to a VIPM
 one. Also note that when calculating the vertices per triangle using triangle
 strips, only drawn triangles should be counted, not degenerate ones. The
-degenerate triangles are a necessary evil – they don’t add anything to the
+degenerate triangles are a necessary evil – they don’t add anything to the
 scene at all.</p>
 
 <p class=MsoNormal>Algorithms that are good at streaming allow
@@ -171,49 +171,49 @@ <h1>Considerations</h1>
 on the machine.</p>
 
 <p class=MsoNormal>This also helps systems with virtual memory
-– if the data is accessed linearly, the virtual memory manager can swap out
+– if the data is accessed linearly, the virtual memory manager can swap out
 data that has yet to be accessed, or has not been accessed for a long time.
 Static data can be optimized even further and made into a read-only
-memory-mapped file. This also ensures that irritating “loading level” messages
+memory-mapped file. This also ensures that irritating “loading level” messages
 are no more tedious than absolutely necessary. The object data does not all
-need to be loaded at the start – the player can start playing the level with
+need to be loaded at the start – the player can start playing the level with
 low-resolution data and as the detailed models are needed, they will be loaded.</p>
 
 <p class=MsoNormal>All the methods discussed here are based
 around implementations of the same fundamental algorithm. Single operations are
 done that collapse a single vertex onto another vertex along one of its
-triangle edges. No new “average” vertex is generated, and no collapses between
+triangle edges. No new “average” vertex is generated, and no collapses between
 vertices that do not share an edge are allowed. These are worth looking into,
 however the current consensus is that they involve a higher runtime cost for
 equivalent error levels on most current hardware. Of course, things change, and
 new algorithms are always being invented.</p>
 
 <p class=MsoNormal>A note on the terminology used. The
-“resolution” of a mesh is proportional to the number or triangles in it. Thus a
-“high-resolution” mesh undergoes edge collapses and becomes a
-“lower-resolution” mesh. The opposite of an edge collapse is an edge “split”,
+“resolution” of a mesh is proportional to the number or triangles in it. Thus a
+“high-resolution” mesh undergoes edge collapses and becomes a
+“lower-resolution” mesh. The opposite of an edge collapse is an edge “split”,
 where a single vertex splits into two separate vertices. For a given
-edge-collapse, there is a “kept” vertex and a “binned” vertex. The binned
+edge-collapse, there is a “kept” vertex and a “binned” vertex. The binned
 vertex is not used in any lower-resolution meshes, the kept vertex is. For a
 given edge collapse, there are two types of triangle. Those that use the edge
-being collapsed will not be in any lower-resolution mesh, and are “binned.” For
+being collapsed will not be in any lower-resolution mesh, and are “binned.” For
 a typical collapse, there are two binned triangles, though there may be more or
 less for complex mesh topologies. Those that are not binned, but use the binned
-vertex are “changed” triangles, and changed so that they use the kept vertex
+vertex are “changed” triangles, and changed so that they use the kept vertex
 instead of the binned vertex. When performing an edge split, the previously
-binned vertex and triangles are “new,” though they are often still called
-“binned” because typically there are no split data structures, just collapse
+binned vertex and triangles are “new,” though they are often still called
+“binned” because typically there are no split data structures, just collapse
 data structures that are done in reverse. Most of the perspective is in the
-collapsing direction, so words like “first”, “next”, “before” and “after” are
+collapsing direction, so words like “first”, “next”, “before” and “after” are
 used assuming collapses from a high-triangle mesh to a low-triangle mesh.
 Again, splits are done by undoing collapses.</p>
 
 <p class=MsoNormal>This gem will also be talking in a very PC
-and DirectX-centric way about CPUs, AGP buses, graphics cards (“the card”),
+and DirectX-centric way about CPUs, AGP buses, graphics cards (“the card”),
 system/video/AGP memory, index and vertex buffers. This is generally just a
-convenience – most consoles have equivalent units and concepts. Where there is
+convenience – most consoles have equivalent units and concepts. Where there is
 a significant difference, they will be highlighted. The one term that may be
-unfamiliar is the AGP bus – this is the bus between the main system memory (and
+unfamiliar is the AGP bus – this is the bus between the main system memory (and
 the CPU) and the graphics card with its memory. There are various speeds, but
 this bus is typically capable of around 500Mbytes/sec, which makes it
 considerably smaller than the buses between system memory and the CPU, and
@@ -253,43 +253,43 @@ <h1>Vanilla VIPM</h1>
 
 <p class=Code>{</p>
 
-<p class=Code>     // The offset of the vertex that doesn't
+<p class=Code>     // The offset of the vertex that doesn't
 vanish/appear.</p>
 
-<p class=Code>     unsigned short  wKeptVert;</p>
+<p class=Code>     unsigned short  wKeptVert;</p>
 
-<p class=Code>     // Number of tris removed/added.</p>
+<p class=Code>     // Number of tris removed/added.</p>
 
-<p class=Code>     unsigned char   bNumTris;</p>
+<p class=Code>     unsigned char   bNumTris;</p>
 
-<p class=Code>     // How many entries in wIndexOffset[].</p>
+<p class=Code>     // How many entries in wIndexOffset[].</p>
 
-<p class=Code>     unsigned char   bNumChanges;</p>
+<p class=Code>     unsigned char   bNumChanges;</p>
 
-<p class=Code>     // How many entries in wIndexOffset[] in
+<p class=Code>     // How many entries in wIndexOffset[] in
 the previous action.</p>
 
-<p class=Code>     unsigned char   bPrevNumChanges;</p>
+<p class=Code>     unsigned char   bPrevNumChanges;</p>
 
-<p class=Code>     // Packing to get correct short alignment.</p>
+<p class=Code>     // Packing to get correct short alignment.</p>
 
-<p class=Code>     unsigned char   bPadding[1];</p>
+<p class=Code>     unsigned char   bPadding[1];</p>
 
 <p class=Code>&nbsp;</p>
 
-<p class=Code>     // The offsets of the indices to change.</p>
+<p class=Code>     // The offsets of the indices to change.</p>
 
-<p class=Code>     // This will be of actual length
+<p class=Code>     // This will be of actual length
 bNumChanges,</p>
 
-<p class=Code>     // then immediately after in memory will be
+<p class=Code>     // then immediately after in memory will be
 the next record.</p>
 
-<p class=Code>     unsigned short  wIndexOffset[];</p>
+<p class=Code>     unsigned short  wIndexOffset[];</p>
 
 <p class=Code>};</p>
 
-<p class=MsoNormal>This structure is not a fixed length – <span style='font-family:monospace'>wIndexOffset[]</span> grows to the number of vertices that need changing. This
+<p class=MsoNormal>This structure is not a fixed length – <span style='font-family:monospace'>wIndexOffset[]</span> grows to the number of vertices that need changing. This
 complicates the access functions slightly, but ensures that when performing
 collapses or splits, all the collapse data is in sequential memory addresses,
 which allows cache lines and cache pre-fetching algorithms to work efficiently.
@@ -298,25 +298,25 @@ <h1>Vanilla VIPM</h1>
 read-only memory-mapped file, which under many operating systems are extremely
 efficient.</p>
 
-<p class=MsoNormal>Although at first glance <span style='font-family:monospace'>bPrevNumChanges </span>doesn’t seem to be needed for collapses, it is needed when doing
-splits and going back up the list – the number of <span style='font-family:monospace'>wIndexOffset[]</span> entries in the previous structure is needed so they can be skipped
+<p class=MsoNormal>Although at first glance <span style='font-family:monospace'>bPrevNumChanges </span>doesn’t seem to be needed for collapses, it is needed when doing
+splits and going back up the list – the number of <span style='font-family:monospace'>wIndexOffset[]</span> entries in the previous structure is needed so they can be skipped
 over. Although this makes for convoluted-looking C, the assembly code produced
 is actually very simple.</p>
 
 <p class=MsoNormal>To perform a collapse, the number of
 vertices used is decremented, since the binned vertex is always the one on the
-end. The number of triangles is reduced by <span style='font-family:monospace'>bNumTris</span> – again, the binned triangles are always the ones on the end of the
+end. The number of triangles is reduced by <span style='font-family:monospace'>bNumTris</span> – again, the binned triangles are always the ones on the end of the
 list.</p>
 
 <p class=MsoNormal>The changed triangles all need to be
 redirected to use the kept vertex instead of the binned one. The offsets of the
 indices that refer to the binned point are held in <span style='font-family:monospace'>wIndexOffset[]</span>. Each one references an index that needs to be changed from the
-binned vertex’s index (which will always be the last one) to the kept vertex’s
-index – <span style='font-family:monospace'>wKeptVert</span>:</p>
+binned vertex’s index (which will always be the last one) to the kept vertex’s
+index – <span style='font-family:monospace'>wKeptVert</span>:</p>
 
 <p class=Code>&nbsp;</p>
 
-<p class=Code>     </p>
+<p class=Code>     </p>
 
 <p class=Code>VanillaCollapseRecord *pVCRCur = the current
 collapse;</p>
@@ -338,10 +338,10 @@ <h1>Vanilla VIPM</h1>
 
 <p class=Code>{</p>
 
-<p class=Code>     ASSERT (
+<p class=Code>     ASSERT (
 pwIndices[pVCRCur-&gt;wIndexOffset[i]] == (unsigned short)iCurNumVerts );</p>
 
-<p class=Code>     pwIndices[pVCRCur-&gt;wIndexOffset[i]] = pVCRCur-&gt;wKeptVert;</p>
+<p class=Code>     pwIndices[pVCRCur-&gt;wIndexOffset[i]] = pVCRCur-&gt;wKeptVert;</p>
 
 <p class=Code>}</p>
 
@@ -349,7 +349,7 @@ <h1>Vanilla VIPM</h1>
 
 <p class=Code>pIndexBuffer-&gt;Unlock();</p>
 
-<p class=Code>// Remember, it’s not a simple ++ (though the
+<p class=Code>// Remember, it’s not a simple ++ (though the
 operator could be overloaded).</p>
 
 <p class=Code>pVCRCur = pVCRCur-&gt;Next();</p>
@@ -358,14 +358,14 @@ <h1>Vanilla VIPM</h1>
 
 <p class=MsoNormal>Note that reading from hardware index
 buffers can be a bad idea on some architectures, so be careful of exactly what
-that <span style='font-family:monospace'>ASSERT()</span> is doing – it is mainly for illustration purposes.</p>
+that <span style='font-family:monospace'>ASSERT()</span> is doing – it is mainly for illustration purposes.</p>
 
 <p class=MsoNormal>&nbsp;</p>
 
 <p class=MsoNormal>[<span style='color:red'>Figure 1 - insert
 VIPM_fig1.SDR]</span></p>
 
-<p class=MsoNormal>Figure 1 – An edge collapse with before and
+<p class=MsoNormal>Figure 1 – An edge collapse with before and
 after index lists and the VanillaCollapseRecord.</p>
 
 <p class=MsoNormal>&nbsp;</p>
@@ -389,10 +389,10 @@ <h1>Vanilla VIPM</h1>
 
 <p class=Code>{</p>
 
-<p class=Code>     ASSERT (
+<p class=Code>     ASSERT (
 pwIndices[pVCRCur-&gt;wIndexOffset[i]] == pVCRCur-&gt;wKeptVert );</p>
 
-<p class=Code>     pwIndices[pVCRCur-&gt;wIndexOffset[i]] =
+<p class=Code>     pwIndices[pVCRCur-&gt;wIndexOffset[i]] =
 (unsigned short)iCurNumVerts;</p>
 
 <p class=Code>}</p>
@@ -407,7 +407,7 @@ <h1>Vanilla VIPM</h1>
 
 <p class=Code>&nbsp;</p>
 
-<p class=MsoNormal>Note – in practice, and for arbitrary
+<p class=MsoNormal>Note – in practice, and for arbitrary
 historical reasons, in the sample code the <span style='font-family:monospace'>VertexCollapseRecords</span> are stored last first, so the <span style='font-family:monospace'>Prev()</span> and <span style='font-family:monospace'>Next()</span> calls are swapped.</p>
 
 <p class=MsoNormal>Vanilla VIPM is simple, easy to code, and
@@ -451,7 +451,7 @@ <h1>Skipstrips</h1>
 very quickly without trying to draw any pixels.</p>
 
 <p class=MsoNormal>This means that the order of triangles is
-no longer determined by collapse order – they can be ordered by some other
+no longer determined by collapse order – they can be ordered by some other
 criteria. The cunning thing that the original SkipStrips paper pointed out is
 that triangles can now be ordered into strip order, and indeed converted into
 strips. This is great for hardware that prefers their data in strip order.
@@ -459,7 +459,7 @@ <h1>Skipstrips</h1>
 despite it being somewhat inaccurate.</p>
 
 <p class=MsoNormal>The ability to reorder triangles increases
-vertex cache coherency. Strips are naturally good at this – they have an
+vertex cache coherency. Strips are naturally good at this – they have an
 implicit 1.0 vertices per triangle efficiency (for long strips with no
 degenerates), and with the right ordering and a decent-sized vertex cache they
 can get much lower values.</p>
@@ -485,13 +485,13 @@ <h1>Skipstrips</h1>
 the indices that refer to it, including the degenerate triangles. So the more
 collapses that get done, the more expensive each collapse becomes, because the
 size of <span style='font-family:monospace'>wIndexOffset[]</span> grows. This does not scale with the number of triangles drawn,
-which is no good, since that is the whole point of VIPM – things at lower
+which is no good, since that is the whole point of VIPM – things at lower
 detail should take less time to render.</p>
 
 <h1>Multi-level Skipstrips</h1>
 
 <p class=MsoNormal>Fortunately, there is a solution to most of
-skipstrip’s woes. After a certain number of collapses, simply stop, take the
+skipstrip’s woes. After a certain number of collapses, simply stop, take the
 current geometry with all of its collapses done, throw away the degenerate
 triangles, and start making a completely new skipstrip from scratch. Continue
 collapses with this new skipstrip until it too becomes inefficient, and so on.</p>
@@ -500,22 +500,22 @@ <h1>Multi-level Skipstrips</h1>
 the degenerate triangles are thrown away, which reduces the number of triangles
 (both visible and degenerate) that are sent to the card. The triangles are also
 reordered to make lists that are again vertex-cache-optimal. New collapses
-don’t need to change lots of degenerate triangle indices each time, each
+don’t need to change lots of degenerate triangle indices each time, each
 instance only needs to copy the skipstrip level that it actually uses, and they
 get shorter with decreasing detail.</p>
 
 <p class=MsoNormal>The different index lists can be stored
 globally, since when switching to a new list a new copy is taken and then
 refined with collapses to exactly the number of triangles wanted. So the fact
-that there are now multiple index lists is not too bad – it’s global data. This
+that there are now multiple index lists is not too bad – it’s global data. This
 also restores some of the nice streaming-friendliness that the vanilla method
-has. The granularity is a bit coarser – the whole of an index list must be
-grabbed before anything can be rendered using that level, but at least it’s no
+has. The granularity is a bit coarser – the whole of an index list must be
+grabbed before anything can be rendered using that level, but at least it’s no
 longer an all-or-nothing thing, and the lower-resolution index lists are
 actually very small.</p>
 
 <p class=MsoNormal>For a bit more efficiency, two versions of
-the index lists can be stored in global space – fully collapsed (before switching
+the index lists can be stored in global space – fully collapsed (before switching
 to a lower-resolution list that is) and fully uncollapsed. This means that a
 single-collapse oscillation across the boundary between two index lists is
 still fairly efficient. If only the uncollapsed versions are held, each time
@@ -529,7 +529,7 @@ <h1>Multi-level Skipstrips</h1>
 global array of structures holding the pre-made index lists, the collapse lists
 for each one, and the number of collapses in each. Before doing any collapses
 or splits, the code checks to see if it needs to change level, and if so copies
-the new level’s index list and starts doing collapses/splits until it reaches
+the new level’s index list and starts doing collapses/splits until it reaches
 the right LoD within that level.</p>
 
 <p class=MsoNormal>So this has fixed all the bad things about
@@ -557,7 +557,7 @@ <h1>Mixed Mode VIPM</h1>
 <p class=MsoNormal>On a multi-level skipstrip, a lot of the
 triangles are not affected even when that level is fully collapsed. So there is
 no need to copy those triangles per-instance; they can be global and shared
-between instances. In fact, for this algorithm indexed lists are used – the
+between instances. In fact, for this algorithm indexed lists are used – the
 indexed strip case will be discussed afterwards as a variant. At each level,
 the triangles are split into four lists:</p>
 
@@ -587,12 +587,12 @@ <h1>Mixed Mode VIPM</h1>
 
 <p class=MsoNormal>To draw the mesh, the required collapses
 and splits are done to the dynamic per-instance list, and the list is drawn.
-Then the associated level’s static list is drawn, with the only modification
+Then the associated level’s static list is drawn, with the only modification
 being that the number of triangles drawn will change as static triangles are
 collapsed.</p>
 
 <p class=MsoNormal>The code and structures needed are based on
-the multi-level skiplist, except that for each level there are two lists – the
+the multi-level skiplist, except that for each level there are two lists – the
 copied dynamic one and the shared static one. The other change is that there
 are two triangle counts, one for each list, and a collapse may alter either or
 both of these numbers. So the <span style='font-family:monospace'>bNumTris</span> member is replaced
@@ -602,7 +602,7 @@ <h1>Mixed Mode VIPM</h1>
 <p class=MsoNormal>This means that a large proportion of each
 mesh is being drawn from a static index buffer that is tuned for vertex cache
 coherency (list 1). It is not quite as good as it could be, since the triangles
-in this list only make up part of the object. There will be “holes” in the mesh
+in this list only make up part of the object. There will be “holes” in the mesh
 where triangles have been moved to the other three lists, and this decreases
 both the maximum and the actual vertex per triangle numbers that are obtained.
 Some of the dynamic buffer is also ordered for optimal vertex cache behavior
@@ -612,9 +612,9 @@ <h1>Mixed Mode VIPM</h1>
 
 <p class=MsoNormal>Like all multi-level methods, it is
 streaming/friendly, though in this case, since the lists are ordered by
-collapse order, the granularity is even finer – at the triangle level, not just
+collapse order, the granularity is even finer – at the triangle level, not just
 the list level. Whether this is a terribly exciting thing is a different
-question – the finer control is probably not going to make much of a difference
+question – the finer control is probably not going to make much of a difference
 to performance.</p>
 
 <p class=MsoNormal>This does require two DrawIndexedPrimitive
@@ -631,7 +631,7 @@ <h1>Mixed Mode Skipstrips</h1>
 means that ordering by collapse order is too inefficient, and this means that list
 2 triangles now have to be binned by being made degenerate. This forces them to
 become dynamic instead of static, and they join lists 3 and 4. The triangles
-from these three lists are merged together and treated as a skipstrip –
+from these three lists are merged together and treated as a skipstrip –
 reordered for optimal vertex cache efficiency, copied for each instance, and
 modified by collapse information.</p>
 
@@ -649,7 +649,7 @@ <h1>Sliding Window</h1>
 therefore a tiny amount of per-instance memory.</p>
 
 <p class=MsoNormal>Sliding window notes that when a collapse
-happens, there are two classes of triangles – binned triangles and modified
+happens, there are two classes of triangles – binned triangles and modified
 triangles. However, there is no real need for the modified triangles to
 actually be at the same physical position in the index buffer before and after
 the collapse. The old version of the triangles could simply drop off the end of
@@ -659,15 +659,15 @@ <h1>Sliding Window</h1>
 <p class=MsoNormal>So instead of an example collapse binning
 two triangles and editing three others, it actually bins five triangles and
 adds three new ones. Both operations are performed by just changing the first
-and last indices used for rendering – sliding a “rendering window” along the
+and last indices used for rendering – sliding a “rendering window” along the
 index buffer.</p>
 
 <p class=MsoNormal>&nbsp;</p>
 
-<p class=MsoNormal>[<span style='color:red'>Figure 2 – insert
+<p class=MsoNormal>[<span style='color:red'>Figure 2 – insert
 VIPM_fig2.sdr]</span></p>
 
-<p class=MsoNormal>Figure 2 – a collapse showing the index
+<p class=MsoNormal>Figure 2 – a collapse showing the index
 list and the two windows.</p>
 
 <p class=MsoNormal>&nbsp;</p>
@@ -680,8 +680,8 @@ <h1>Sliding Window</h1>
 Note that a triangle modified as the result of a collapse cannot then be
 involved (either binned or changed) in another collapse. To be modified by a
 second collapse would mean that triangle would have to fall off the end of the
-index buffer. But it has already been added to the start – it cannot then also
-fall off the end – the chance of the ordering being just right to allow this
+index buffer. But it has already been added to the start – it cannot then also
+fall off the end – the chance of the ordering being just right to allow this
 are incredibly slim.</p>
 
 <p class=MsoNormal>So once a triangle has been modified by a
@@ -704,9 +704,9 @@ <h1>Sliding Window</h1>
 <p class=MsoNormal>However, there is actually no need to
 strictly follow the order of collapses that QEM decides. Progressive meshing is
 not an exact science, since it ignores everything but the distance of the
-camera from the object, and the whole point is to simply be “good enough” to
+camera from the object, and the whole point is to simply be “good enough” to
 fool the eye. So there is no real need to precisely follow the collapse order
-that QEM decides – it can be manipulated a bit.</p>
+that QEM decides – it can be manipulated a bit.</p>
 
 <p class=MsoNormal>The way to do this is to follow the QEM
 collapse order until it decides to do a collapse that involves triangles that
@@ -736,7 +736,7 @@ <h1>Sliding Window</h1>
 <p class=MsoNormal>Since no runtime modification is made to
 the index or vertex lists, all the data can be made global, and there is almost
 zero instance memory use. There is also almost zero CPU use to change level of
-detail – each time a simple table lookup is made to decide the index list to
+detail – each time a simple table lookup is made to decide the index list to
 use, the start and end index to draw from that index list, and how many
 vertices are used. In practice, the index lists are concatenated together, so
 that the start index also implies the index list to use. The table is composed
@@ -748,11 +748,11 @@ <h1>Sliding Window</h1>
 
 <p class=Code>{</p>
 
-<p class=Code>     unsigned int    dwFirstIndexOffset;</p>
+<p class=Code>     unsigned int    dwFirstIndexOffset;</p>
 
-<p class=Code>     unsigned short  wNumTris;</p>
+<p class=Code>     unsigned short  wNumTris;</p>
 
-<p class=Code>     unsigned short  wNumVerts;</p>
+<p class=Code>     unsigned short  wNumVerts;</p>
 
 <p class=Code>};</p>
 
@@ -772,42 +772,42 @@ <h1>Sliding Window</h1>
 
 <p class=Code>d3ddevice-&gt;DrawIndexedPrimitive (</p>
 
-<p class=Code>     D3DPT_TRIANGLELIST,                   //
+<p class=Code>     D3DPT_TRIANGLELIST,                   //
 Primitive type</p>
 
-<p class=Code>     0,                                    //
+<p class=Code>     0,                                    //
 First used vertex</p>
 
-<p class=Code>     pswr-&gt;wNumVerts,                           //
+<p class=Code>     pswr-&gt;wNumVerts,                           //
 Number of used vertices</p>
 
-<p class=Code>     pswr-&gt;dwFirstIndexOffset,             //
+<p class=Code>     pswr-&gt;dwFirstIndexOffset,             //
 First index</p>
 
-<p class=Code>     pswr-&gt;wNumTris );                          //
+<p class=Code>     pswr-&gt;wNumTris );                          //
 Number of triangles</p>
 
 <p class=Code>&nbsp;</p>
 
 <p class=MsoNormal>There is no code to do splits or collapses
-as with all the other methods – the current LoD is just looked up in the
+as with all the other methods – the current LoD is just looked up in the
 SlidingWindowRecord table each time the object is rendered. This also means
 that with hardware transform and lighting cards, the CPU time required to
 render objects is fixed and constant per object, whatever their level of
-detail. The phrase “constant time” is always a good one to find lurking in any
+detail. The phrase “constant time” is always a good one to find lurking in any
 algorithm.</p>
 
 <p class=MsoNormal>The major problem with sliding window VIPM
 is that it forces the ordering of the triangles at the start and end of each
-level’s index lists. This has two effects – one is that it makes strips hard to
-use – only triangle lists really handle fixed-ordering well. The other is that
+level’s index lists. This has two effects – one is that it makes strips hard to
+use – only triangle lists really handle fixed-ordering well. The other is that
 vertex cache efficiency is affected.</p>
 
 <p class=MsoNormal>Fortunately, it is not as bad as it first
 seems. When an edge collapse is performed, all the triangles that use the
 binned vertex are removed, so they all go on the end of the triangle list. This
 is typically from five to seven triangles, and they form a triangle fan around
-the binned vertex. Then the new versions of the triangles are added – these
+the binned vertex. Then the new versions of the triangles are added – these
 need to go together at the start of the index list, there are typically three
 to five of them, and they form a triangle fan around the kept vertex. These
 fans can be ordered within themselves to get the best cache coherency. The
@@ -817,7 +817,7 @@ <h1>Sliding Window</h1>
 not unreasonably poor.</p>
 
 <p class=MsoNormal>Vertex cache coherency can be raised by
-having a larger middle index list section in each level – by having fewer
+having a larger middle index list section in each level – by having fewer
 collapses per level. This takes more memory, but the extra performance may be
 worth it, especially as it is global memory.</p>
 
@@ -825,7 +825,7 @@ <h1>Sliding Window</h1>
 lists can still use this method, though it does require a lot of degenerate
 triangles to join the different parts up. In practice, this does not increase
 the number of indices required, it actually reduces it - strips have one index
-per triangle, compared to a list’s three. The vertex cache efficiency per drawn
+per triangle, compared to a list’s three. The vertex cache efficiency per drawn
 triangle is exactly the same. The raw triangle throughput is increased a lot
 (roughly doubled), but since all these extra triangles are just degenerate,
 most hardware will reject them very quickly. If there is a choice, which of the
@@ -841,14 +841,14 @@ <h1>Summary</h1>
 CPU buck (though it is worth noting that VDPM methods are still challengers for
 large landscapes, especially regular-height-field ones). And now it has a
 plethora of methods to choose from, each with its own advantages and
-disadvantages. Innovation certainly won’t stop there – there are already some
-interesting paths for future investigation – but this roundup should give a
+disadvantages. Innovation certainly won’t stop there – there are already some
+interesting paths for future investigation – but this roundup should give a
 fairly good guide to some of the issues and options when choosing which VIPM
 method to implement.</p>
 
 <p class=MsoNormal>Table 1 shows the results of each method
-with their relative strengths and weaknesses. Note that “skipstrips” refers to
-multi-level skipstrips – the single-level version is not actually a sensible
+with their relative strengths and weaknesses. Note that “skipstrips” refers to
+multi-level skipstrips – the single-level version is not actually a sensible
 method in practice, for the reasons given.</p>
 
 <p class=MsoNormal>&nbsp;</p>
@@ -912,8 +912,8 @@ <h1>Summary</h1>
 
 <h1>References</h1>
 
-<p class=Hanging>[Svarovsky00] Svarovsky, Jan. “View-independent 
-Progressive Meshing”, Games Programming Gems 1, ISBN 1584500492.
+<p class=Hanging>[Svarovsky00] Svarovsky, Jan. “View-independent 
+Progressive Meshing”, Games Programming Gems 1, ISBN 1584500492.
 A similar talk was given at GDC99, available from 
 <a href="http://www.svarovsky.org/ExtremeD/">
 http://www.svarovsky.org/ExtremeD/</a>.</p>
@@ -923,14 +923,14 @@ <h1>References</h1>
 <a href="http://www.cbloom.com/3d/index.html">
 http://www.cbloom.com/3d/index.html</a></p>
 
-<p class=Hanging>[Hoppe99] Hoppe, Hugues. “Optimization of
-Mesh Locality for Transparent Vertex Caching”, Computer Graphics (SIGGRAPH 1999
+<p class=Hanging>[Hoppe99] Hoppe, Hugues. “Optimization of
+Mesh Locality for Transparent Vertex Caching”, Computer Graphics (SIGGRAPH 1999
 proceedings) pages 269-276. Also from <a href="http://www.research.microsoft.com/~hoppe/">
 http://www.research.microsoft.com/~hoppe/</a></p>
 
 <p class=Hanging>[El-Sana99] J. El-Sana, F. Evans, A. Varshney,
-S. Skiena, E. Azanli,. “Efficiently Computing and Updating Triangle Strips for
-View-Dependent Rendering” The Journal of Computer Aided Design Vol 32, IS 13,
+S. Skiena, E. Azanli,. “Efficiently Computing and Updating Triangle Strips for
+View-Dependent Rendering” The Journal of Computer Aided Design Vol 32, IS 13,
 pages 753-772. Also from at <a href="http://www.cs.bgu.ac.il/~el-sana/publication.html">
 http://www.cs.bgu.ac.il/~el-sana/publication.html</a></p>
 
@@ -948,27 +948,27 @@ <h1>References</h1>
 It's also been slightly updated from the original in light of experience with
 Blade 2 - of which there is more below in the Hindsights section)</p>
 
-<h1>Raison d’Etre</h1>
+<h1>Raison d’Etre</h1>
 
 <p class=MsoNormal>It is worth noting a few misconceptions about VIPM that have
 cropped up in discussions with people.</p>
 
 <p class=MsoNormal>First, VIPM is not aimed at getting low-end machines running
 faster. It can have this side effect in many cases, but that is not its primary
-aim. This may surprise many people – increasing speed on slow machines is often
+aim. This may surprise many people – increasing speed on slow machines is often
 assumed to be the whole point of VIPM, and many approach it with this in mind.
 However, with low-end machines you need to render objects with as few tris as
 possible. The problem with most forms of VIPM is that they produce very poor
 low-tri representations of objects, at least when compared to the output of a
 good 3D artist given the same triangle budget. If the aim of an engine is to
 run well on low-end machines, getting an artist to author good low-tri models
-is really the only way to proceed – they produce far better looking 200-tri people
+is really the only way to proceed – they produce far better looking 200-tri people
 than any automated VIPM routine can.</p>
 
 <p class=MsoNormal>The real aim of VIPM is to allow artists to author high-tri
 models for use on high-end platforms, but allowing the extra triangle detail to
 be used where it matters in a scene, without burning the triangle budget on
-unnoticed background detail. This is the real power of scalability techniques –
+unnoticed background detail. This is the real power of scalability techniques –
 the ability to have lots of extremely detailed models in a scene, but only
 showing the detail that is visible at any one time. The fact that by tweaking a
 few global values, lower-end machines can use all the detail their available
@@ -1013,7 +1013,7 @@ <h1>References</h1>
 alpha-blend between the different LoDs. This produces a smooth
 change, but does mean that pixel fillrate is increased dramatically. Not only
 is the object being drawn (and animated and lit and so on) twice, but both
-passes (yes, both, not just one – think about it) need to use alpha-blending,
+passes (yes, both, not just one – think about it) need to use alpha-blending,
 which is more expensive than normal rendering. And if the object normally has
 alpha-blended parts, then things can get a bit tricky trying to achieve the
 right effect while doing the blend. This effect used to be used by the 
@@ -1033,11 +1033,11 @@ <h1>Error Metrics</h1>
 barely mentioned in the printed text. However, a quick word is in order.</p>
 
 <p class=MsoNormal>Many people including myself have had excellent results with
-Garland and Heckbert’s Quadric Error Metrics [GarlandHeckbert97],
+Garland and Heckbert’s Quadric Error Metrics [GarlandHeckbert97],
 and the further refinements introduced by Hoppe [Hoppe99]
 for vertex attributes such as colour, texture co-ordinate and so on. The maths
 of the academic papers can be initially intimidating, but the implementation is
-actually very simple, versatile and quick. A very naďve version of the basic
+actually very simple, versatile and quick. A very naĂŻve version of the basic
 Garland-Heckbert QEM is included in the code, mainly so that the
 data generated is representative of real VIPM collapse orders.</p>
 
@@ -1048,7 +1048,7 @@ <h1>Error Metrics</h1>
 ensure that the QEM is guided to collapse the object down from one to the
 other. The other way is to start with the low-poly mesh and work upwards, 
 tessellating towards the high-poly mesh. There are several ways to do this 
-– one that has some other very nice properties is discussed in a talk I 
+– one that has some other very nice properties is discussed in a talk I 
 gave at the Windows Games Developer Conference 2000 [Forsyth00].</p>
 
 <h1>Hybrids</h1>
@@ -1067,10 +1067,10 @@ <h1>Hybrids</h1>
 
 <p class=MsoNormal>At the low tri levels, sliding window could be used.
 Although it has a comparatively low vertex cache efficiency, the objects are at
-such low triangle levels that they don’t actually make up much of the scene’s
+such low triangle levels that they don’t actually make up much of the scene’s
 triangle budget. However, there are a lot of them, and sliding window not only
 has near-zero memory per instance, but also changes LoD in constant (and 
-nearly zero) time – always a good characteristic when the number of separate 
+nearly zero) time – always a good characteristic when the number of separate 
 objects is high. Another side effect is that since these are low tri levels, 
 the number of sliding window levels can be increased without too much memory 
 bloat. As noted above, this increases the vertex cache coherency, if that is 
@@ -1087,15 +1087,15 @@ <h1>Surprises</h1>
 were aiming for a fairly conventional (some might say low) frame rate of 30Hz.
 And I assumed that the vanilla VIPM method was at least only copying the
 indices it was currently using, with some hysteresis to avoid <span style='font-family:monospace'>
-malloc()</span>-thrashing –
+malloc()</span>-thrashing –
 say a 30% over-estimation.</p>
 
 <p class=MsoNormal>So 20Mtri/sec at 30Hz means 667ktris per frame. Assuming
 those are all from vanilla VIPM objects, and they were all unique (neither of
-which is true – most scenes have some objects rendered with multiple passes as
+which is true – most scenes have some objects rendered with multiple passes as
 well as non-VIPM objects such as particle effects), and assuming the 30%
 over-estimation, that means 867ktris held in VIPM object index buffers each
-frame. We’re using WORD indices, and triangle lists, so 6 bytes per triangle.
+frame. We’re using WORD indices, and triangle lists, so 6 bytes per triangle.
 Which gives 5.20Mbytes. Which is a decent chunk, but not actually all that much
 considering this is the worst-case scenario on the (current) best hardware,
 being driven at peak efficiency at a fairly modest frame rate. This machine
@@ -1114,14 +1114,14 @@ <h1>Surprises</h1>
 be. The obvious benefits are no per-instance memory use and virtually no CPU
 use. I worried that the memory for the index lists would be too large, but in
 fact it is of comparable size to the vertex data, and certainly not particularly
-large by today’s standards. Playing with the sample code with your own models
+large by today’s standards. Playing with the sample code with your own models
 will show that the memory use, even for single instances, is pretty reasonable.</p>
 
 <p class=MsoNormal>The other big weakness of sliding window was going to be the
-vertex cache coherency. But in fact it’s not too bad. The fragmented start and
+vertex cache coherency. But in fact it’s not too bad. The fragmented start and
 end of each index level are bad, but they are still fans, rather than
 individual triangles, so not mad. For a typical mesh, the tri fans at the start
-of the list will have four tris and reference six vertices – a rate of 1.5
+of the list will have four tris and reference six vertices – a rate of 1.5
 verts per tri. Not very good, but not stupidly bad. The tri fans at the end of
 the list typically have six tris and reference seven verts (remember that they
 form a complete fan around the binned vert), a rate of 1.17 tris per vert.
@@ -1138,7 +1138,7 @@ <h1>Surprises</h1>
 tolerance, have fewer collapses per level, and thus have more tris in the
 optimal middle section. This does chew more memory of course. But there is no
 need to use this lower tolerance uniformly. The really expensive bits are the
-first few levels – they have a lot of indices in them, and each level
+first few levels – they have a lot of indices in them, and each level
 replicates all that data. Fortunately, few objects are close enough to the
 camera to use these levels, so having a low vertex cache efficiency for these
 few objects is tolerable.</p>
@@ -1152,10 +1152,10 @@ <h1>The Sample Code</h1>
 
 <p class=MsoNormal>The sample code has a number of features to be aware of. It
 does not handle multiple objects, just multiple instances of the same object.
-It does not handle materials – everything is just Gouraud-shaded white. It does
-not try to deal sensibly with seams and edges of meshes – it simply avoids
+It does not handle materials – everything is just Gouraud-shaded white. It does
+not try to deal sensibly with seams and edges of meshes – it simply avoids
 doing any collapses on them at all. It does not take normals into account when
-computing collapse errors, only vertex positions – the normals are simply there
+computing collapse errors, only vertex positions – the normals are simply there
 for display purposes. In short, the collapse-generation algorithm does only
 just enough work to generate representative collapse orders, so as not to skew
 the comparison of the various methods. All these problems are interesting and
@@ -1165,20 +1165,20 @@ <h1>The Sample Code</h1>
 <p class=MsoNormal>It is worth noting that sitting an artist down and getting
 them to click on each edge to determine the collapse order is not that mad an
 idea. It takes less time than you might think, and keeps all the control in the
-artist’s hands. When the model is millions of tris, it’s a bit impractical, but
+artist’s hands. When the model is millions of tris, it’s a bit impractical, but
 at that level an automated collapse finder gets good results. All the errors
-are small, so it’s hard to produce obviously wrong results. Once an object gets
+are small, so it’s hard to produce obviously wrong results. Once an object gets
 below a few thousand triangles, even the best QEM methods start to struggle,
 and that sort of tri count is low enough for an artist to spend time doing the
 rest by hand. In the grey area in between, using a mainly automated system with
 the artist watching and occasionally forcing an early collapse or (more
 frequently) forbidding collapses that the error metric has mistakenly labelled
-as “low error” works quite well. <i>(note - this paragraph is somewhat 
+as “low error” works quite well. <i>(note - this paragraph is somewhat 
 theoretical - see the "Hindsights" section below for what we ended up 
 actually using for VIPM in Blade 2)</i></p>
 
 <p class=MsoNormal>The sample code also does not attempt to choose the level of
-detail of objects in any particularly sensible way – it just aims roughly for a
+detail of objects in any particularly sensible way – it just aims roughly for a
 set number of triangles (or rather collapses) at a certain distance from the
 camera. Again, the aim is to get representative comparisons of the various
 methods, rather than to actually get good visual quality. In practice, the
@@ -1190,8 +1190,8 @@ <h1>The Sample Code</h1>
 
 <h1>Future Possibilities</h1>
 
-<p class=MsoNormal>All these methods use the same fundamental algorithm – a
-vertex is collapsed along an edge to another vertex. No new “average” vertex
+<p class=MsoNormal>All these methods use the same fundamental algorithm – a
+vertex is collapsed along an edge to another vertex. No new “average” vertex
 is generated. It should be noted that calculating an average vertex position is
 tricky (the straight linear average is not a good approximation in many cases),
 and many dispute whether it gives much of a useful increase in detail for the
@@ -1202,7 +1202,7 @@ <h1>Future Possibilities</h1>
 of the low-tri model may simply not exist in the high-tri model, and so need to
 be added at some stage during the collapse.</p>
 
-<p class=MsoNormal>Anyway, there are two ways to do this – add those average
+<p class=MsoNormal>Anyway, there are two ways to do this – add those average
 vertices into the global vertex buffer along with the originals, or make the
 vertex buffer a per-instance resource and when the collapse is made, replace
 one of the vertices with the new average data. </p>
@@ -1222,13 +1222,13 @@ <h1>Future Possibilities</h1>
 pipelines because of they way they like to start at one place in the vertex
 buffer and process a given number of vertices in a row. Vertices in the vertex
 buffer that are not referenced by indices are still transformed and lit, and
-since this is the major cost in a software T&amp;L system, it’s not efficient.
+since this is the major cost in a software T&amp;L system, it’s not efficient.
 However, if only hardware T&amp;L systems are being considered (e.g. very
 high-end machines only, or consoles) then a vertex buffer with unused vertices
-in it is not such a bad thing – vertices never referenced are never fetched,
+in it is not such a bad thing – vertices never referenced are never fetched,
 transformed or lit.</p>
 
-<p class=MsoNormal>However, using something similar to the “sliding window”
+<p class=MsoNormal>However, using something similar to the “sliding window”
 algorithm, but for vertices instead of triangles, would solve both problems.
 The vertex data would still be global, not per-instance; there is no runtime
 modification of it, it has no holes, and the memory use can be kept
@@ -1249,16 +1249,16 @@ <h1>Future Possibilities</h1>
 talks about AGP - but the same points are still valid)</i></p>
 
 <p class=MsoNormal>Using the sliding window method for vertices would again
-allow the central region to be ordered optimally – typically simply in the
+allow the central region to be ordered optimally – typically simply in the
 order that tris use them. This means that the lookahead reads that the system
 memory bus does are more likely to be correct, and also allows the AGP more
 chance to squirt linear chunks of memory at the graphics card. Even though it
-doesn’t directly affect vertex cache coherency, it does increase the effective
+doesn’t directly affect vertex cache coherency, it does increase the effective
 bandwidth of the AGP bus, and that is increasingly becoming the bottleneck in
-today’s graphics cards.</p>
+today’s graphics cards.</p>
 
 <p class=MsoNormal>Another future possibility is to extend the code to use the
-“limited instance” idea. Use something like skipstrips, but instead of having
+“limited instance” idea. Use something like skipstrips, but instead of having
 one instance per on-screen object, the number of instances is set to a fixed
 (fairly low) number. When an object needs rendering at a certain LoD, take the
 instance that is currently closest to this LoD and collapse/split it until the
@@ -1274,14 +1274,14 @@ <h1>Future Possibilities</h1>
 
 <h1>References</h1>
 
-<p class=Hanging>[GarlandHeckbert97] Garland, Heckbert, . “Surface Simplification Using Quadric Error Metrics”, SIGGRAPH 97. Also from <a href="http://graphics.cs.uiuc.edu/~garland/research/quadrics.html">
+<p class=Hanging>[GarlandHeckbert97] Garland, Heckbert, . “Surface Simplification Using Quadric Error Metrics”, SIGGRAPH 97. Also from <a href="http://graphics.cs.uiuc.edu/~garland/research/quadrics.html">
 http://graphics.cs.uiuc.edu/~garland/research/quadrics.html</a></p>
 
-<p class=Hanging>[Hoppe99] Hoppe, Hugues. “New quadric metric for simplifying meshes with appearance attributes”, IEEE Visualization 1999, October 1999, 59-66. Also from
+<p class=Hanging>[Hoppe99] Hoppe, Hugues. “New quadric metric for simplifying meshes with appearance attributes”, IEEE Visualization 1999, October 1999, 59-66. Also from
 <a href="http://research.microsoft.com/~hoppe/">
 http://research.microsoft.com/~hoppe/</a></p>
 
-<p class=Hanging>[Forsyth00] Forsyth, Tom. “Where have all the bumpmaps gone?”, Meltdown 2000. Also from
+<p class=Hanging>[Forsyth00] Forsyth, Tom. “Where have all the bumpmaps gone?”, Meltdown 2000. Also from
 <a href="http://www.eelpi.gotdns.org/papers/papers.html">
 http://www.eelpi.gotdns.org/papers/papers.html</a></p>
 
diff --git a/papers/papers.html b/papers/papers.html
index 8d13aea..dc09ceb 100644
--- a/papers/papers.html
+++ b/papers/papers.html
@@ -94,7 +94,7 @@ <h1>HTML versions of older articles.</h1>
 <br>
 <a href="gem_vipm_webversion.html">Comparison of VIPM Methods</a><br>
 <br>
-<a href="gem_imp_filt.html">Impostors – Adding Clutter</a><br>
+<a href="gem_imp_filt.html">Impostors – Adding Clutter</a><br>
 <br>
 <a href="cellular_automata_for_physical_modelling.html">Cellular Automata for Physical Modelling</a><br>
 <br>
diff --git a/papers/trilight/trilight.html b/papers/trilight/trilight.html
index 35b7eec..7724760 100644
--- a/papers/trilight/trilight.html
+++ b/papers/trilight/trilight.html
@@ -181,7 +181,7 @@ <h1 align=center style='text-align:center'>A simple general-purpose lighting
 
 <p class=MsoNormal><o:p>&nbsp;</o:p></p>
 
-<p class=MsoNormal>A “<span class=SpellE>trilight</span>” lighting equation is
+<p class=MsoNormal>A “<span class=SpellE>trilight</span>” lighting equation is
 a generalisation of a bunch of lighting models people have used in games over
 the years:</p>
 
@@ -206,16 +206,16 @@ <h3>Wrap-around lighting</h3>
 <p class=MsoNormal><o:p>&nbsp;</o:p></p>
 
 <p class=MsoNormal>The problem with pure Lambert lighting is that 50% of your
-model is completely dark, so the back side doesn’t really show up very well
+model is completely dark, so the back side doesn’t really show up very well
 without adding more lights. A wrap-around light is a very crude simulation of
 the light scattering back from the surroundings and lighting the back side to
 some extent. This has been used by a variety of games for ages, but the first
-place I’ve seen it actually documented was in an aside in an article about Half
-Life 2’s lighting model.</p>
+place I’ve seen it actually documented was in an aside in an article about Half
+Life 2’s lighting model.</p>
 
 <p class=MsoNormal><o:p>&nbsp;</o:p></p>
 
-<p class=MsoNormal>“<span class=GramE>factor</span>” ranges from 0 to 1, with
+<p class=MsoNormal>“<span class=GramE>factor</span>” ranges from 0 to 1, with
 many games just hard-wiring it to 1.</p>
 
 <p class=MsoNormal><o:p>&nbsp;</o:p></p>
@@ -227,10 +227,10 @@ <h3>Hemispherical lighting</h3>
 <p class=MsoNormal><span class=SpellE><span class=GramE>res</span></span> =
 lerp ( colour2, colour0, (N.L+1)/2 )</p>
 
-<p class=MsoNormal><span style='mso-tab-count:1'>            </span>= colour2 +
+<p class=MsoNormal><span style='mso-tab-count:1'>            </span>= colour2 +
 (colour0-colour2) * (N.L+1)/2</p>
 
-<p class=MsoNormal><span style='mso-tab-count:1'>            </span>=
+<p class=MsoNormal><span style='mso-tab-count:1'>            </span>=
 (colour0+colour2)/2 + (colour0-colour2) * (N.L)/2</p>
 
 <p class=MsoNormal><o:p>&nbsp;</o:p></p>
@@ -238,14 +238,14 @@ <h3>Hemispherical lighting</h3>
 <p class=MsoNormal>This has also been used in many games for ages, but the
 first time I remember seeing it actually documented was in a talk by Chas Boyd
 of Microsoft talking about more interesting light models. This is good for
-outdoor scenes – typically the colours are a light blue for the sky and a dark
+outdoor scenes – typically the colours are a light blue for the sky and a dark
 greenish/brown for the ground. These are the preset colours in the <span
 class=SpellE>trilight</span> demo.</p>
 
 <p class=MsoNormal><o:p>&nbsp;</o:p></p>
 
-<p class=MsoNormal>Note – I’ve used colour0 and colour2, missing out colour1 to
-be consistent with the <span class=SpellE>trilight’s</span> terminology below.</p>
+<p class=MsoNormal>Note – I’ve used colour0 and colour2, missing out colour1 to
+be consistent with the <span class=SpellE>trilight’s</span> terminology below.</p>
 
 <p class=MsoNormal><o:p>&nbsp;</o:p></p>
 
@@ -258,8 +258,8 @@ <h3>Bi-directional lighting</h3>
 
 <p class=MsoNormal><o:p>&nbsp;</o:p></p>
 
-<p class=MsoNormal>Yet another lighting model used for ages. The first place I’ve
-seen it documented is in an article on <span class=SpellE>Tabula</span> Rasa’s
+<p class=MsoNormal>Yet another lighting model used for ages. The first place I’ve
+seen it documented is in an article on <span class=SpellE>Tabula</span> Rasa’s
 rendering model in an upcoming GPU Gems book. This is distinct from the
 hemispherical lighting model because a lit sphere will have a ring around the
 middle between the two lights. In hemispherical lighting, this ring is the
@@ -269,8 +269,8 @@ <h3>Bi-directional lighting</h3>
 <p class=MsoNormal><o:p>&nbsp;</o:p></p>
 
 <p class=MsoNormal>This lighting model is a cheap approximation of the classic
-movie lighting of “key” and “fill” lights. The usual example is at night - a
-bright yellow “key” light from a streetlamp and a dark-blue “fill” light from
+movie lighting of “key” and “fill” lights. The usual example is at night - a
+bright yellow “key” light from a streetlamp and a dark-blue “fill” light from
 the night sky to give shape to the dark parts of the character. In fact usually
 the fill is not directly opposite the key light, but this is a very similar
 effect and is basically free.</p>
@@ -288,8 +288,8 @@ <h3>The <span class=SpellE>Trilight</span> Model</h3>
 
 <p class=MsoNormal>The idea of the <span class=SpellE>trilight</span> is to
 unify all the above lighting models into one. As a bonus, it also gives more
-control than any one of them. In the same way that I’ve never seen the above
-lighting models documented until fairly recently, but I know they’ve been used
+control than any one of them. In the same way that I’ve never seen the above
+lighting models documented until fairly recently, but I know they’ve been used
 for ages, I suspect this model has been used by others even before I did (which
 I think was sometime in 2002). But I thought it was time to write the thing
 down so that everyone could use it.</p>
@@ -297,7 +297,7 @@ <h3>The <span class=SpellE>Trilight</span> Model</h3>
 <p class=MsoNormal><o:p>&nbsp;</o:p></p>
 
 <p class=MsoNormal>The <span class=SpellE>trilight</span> is obviously a superset
-of Lambert and bi-directional – simply set colour1 and/or colour2 to black.</p>
+of Lambert and bi-directional – simply set colour1 and/or colour2 to black.</p>
 
 <p class=MsoNormal><o:p>&nbsp;</o:p></p>
 
@@ -311,19 +311,19 @@ <h3>The <span class=SpellE>Trilight</span> Model</h3>
 <p class=MsoNormal style='text-indent:36.0pt'><span class=SpellE><span
 class=GramE>trilight</span></span> = colour0 * (N.L) + colour1 * (1-(N.L))</p>
 
-<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
+<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
 colour0 * (N.L) + colour1 - colour1 * (N.L)</p>
 
-<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
+<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
 (colour0-colour1) * (N.L) + colour1</p>
 
-<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
+<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
 (colour0-(colour0+colour2)/2) * (N.L) + (colour0+colour2)/2</p>
 
-<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
+<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
 ((colour0-colour2)/2) * (N.L) + (colour0+colour2)/2</p>
 
-<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
+<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
 same as hemispherical</p>
 
 <p class=MsoNormal>For N.L &lt; 0:</p>
@@ -331,16 +331,16 @@ <h3>The <span class=SpellE>Trilight</span> Model</h3>
 <p class=MsoNormal style='text-indent:36.0pt'><span class=SpellE><span
 class=GramE>trilight</span></span> = colour1 * (1+(N.L)) - colour2 * (N.L)</p>
 
-<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
+<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
 -colour2 * (N.L) + colour1 + colour1 * (N.L)</p>
 
-<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
+<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
 (colour1-colour2) * (N.L) + colour1</p>
 
-<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
+<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
 ((colour0+colour2)/2-colour2) * (N.L) + (colour0+colour2)/2</p>
 
-<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
+<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
 ((colour0-colour2)/2) * (N.L) + (colour0+colour2)/2</p>
 
 <p class=MsoNormal style='margin-left:36.0pt;text-indent:36.0pt'>= same as
@@ -354,7 +354,7 @@ <h3>The <span class=SpellE>Trilight</span> Model</h3>
 
 <p class=MsoNormal>The <span class=SpellE>trilight</span> is very close to wrap-around
 lighting when colour2 = black, colour1 = factor*colour0/2. This is only an
-approximation, but it’s pretty close as you can see from the demo and from the
+approximation, but it’s pretty close as you can see from the demo and from the
 following:</p>
 
 <p class=MsoNormal><o:p>&nbsp;</o:p></p>
@@ -367,10 +367,10 @@ <h3>The <span class=SpellE>Trilight</span> Model</h3>
 <p class=MsoNormal style='margin-left:36.0pt;text-indent:36.0pt'>= colour0 *
 (N.L) + factor *colour0* (1-(N.L))/2</p>
 
-<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
+<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
 colour0 * ((N.L) + factor /2 - factor *(N.L)/2)</p>
 
-<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
+<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
 colour0 * ((N.L)*(2- factor) + factor))/2</p>
 
 <p class=MsoNormal>For N.L &lt; 0:</p>
@@ -378,13 +378,13 @@ <h3>The <span class=SpellE>Trilight</span> Model</h3>
 <p class=MsoNormal style='text-indent:36.0pt'><span class=SpellE><span
 class=GramE>trilight</span></span> = colour1 * (1+(N.L)) - colour2 * (N.L)</p>
 
-<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
+<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
 colour1 * (1<span class=GramE>+(</span>N.L))</p>
 
-<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
+<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
 factor *colour0 * (1<span class=GramE>+(</span>N.L))/2</p>
 
-<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
+<p class=MsoNormal style='text-indent:36.0pt'><span style='mso-tab-count:1'>            </span>=
 colour0 * (factor /2) * ((N.L<span class=GramE>)+</span>1)</p>
 
 <p class=MsoNormal style='text-indent:36.0pt'><o:p>&nbsp;</o:p></p>
@@ -401,7 +401,7 @@ <h3>The <span class=SpellE>Trilight</span> Model</h3>
 can see how the two curves differ at this value, and by toggling on and off <span
 class=SpellE>trilight</span> emulation in the demo, you can see that there is a
 redistribution of shade from light to dark areas, causing a slight washing-out
-of contrast. However, changing the “factor” value is done in response to moving
+of contrast. However, changing the “factor” value is done in response to moving
 from a stark, purely-<span class=SpellE>Lambertian</span> lighting environment
 into an environment with more back-lighting from indirect bounces, so the whole
 thing is just an approximation anyway. As previously mentioned, many games just
@@ -440,7 +440,7 @@ <h3>The Demo</h3>
 <p class=MsoNormal><o:p>&nbsp;</o:p></p>
 
 <p class=MsoNormal>You probably want to make the demo <span class=SpellE>fullscreen</span>
-– <span class=GramE>there’s</span> a lot of sliders in the bottom right. From
+– <span class=GramE>there’s</span> a lot of sliders in the bottom right. From
 top to bottom:</p>
 
 <p class=MsoNormal><o:p>&nbsp;</o:p></p>
@@ -448,21 +448,21 @@ <h3>The Demo</h3>
 <ul style='margin-top:0cm' type=disc>
  <li class=MsoNormal style='mso-list:l0 level1 lfo1;tab-stops:list 36.0pt'>The
      three colours, each with a red, green and blue slider. Move the slides to
-     change the colours. Some light types don’t use some of the colours.</li>
+     change the colours. Some light types don’t use some of the colours.</li>
  <li class=MsoNormal style='mso-list:l0 level1 lfo1;tab-stops:list 36.0pt'>The
-     light factor – only used for the wraparound light type. 0 = no wraparound,
+     light factor – only used for the wraparound light type. 0 = no wraparound,
      1= full wraparound.</li>
  <li class=MsoNormal style='mso-list:l0 level1 lfo1;tab-stops:list 36.0pt'>The
-     light type – <span class=GramE>this switches</span> between the five light
+     light type – <span class=GramE>this switches</span> between the five light
      types in this article.</li>
  <li class=MsoNormal style='mso-list:l0 level1 lfo1;tab-stops:list 36.0pt'>Enable
      <span class=SpellE>trilight</span> emulation. When selected, this uses a <span
      class=SpellE>trilight</span> emulation of the light type instead of using
      the real lighting equation. As said above, this emulation is perfect
-     except in the case of the wraparound light – by selecting that type and
+     except in the case of the wraparound light – by selecting that type and
      toggling this button on and off, you can see the slight differences.</li>
  <li class=MsoNormal style='mso-list:l0 level1 lfo1;tab-stops:list 36.0pt'>Enable
-     <span class=SpellE>preshaders</span>. <span class=SpellE>Ooops</span> –
+     <span class=SpellE>preshaders</span>. <span class=SpellE>Ooops</span> –
      left over from the D3D demo I started with. Ignore it.</li>
  <li class=MsoNormal style='mso-list:l0 level1 lfo1;tab-stops:list 36.0pt'>Change
      model. Toggles the model between a spiky-haired young lady and a sphere.</li>