Procedural Data - Revision history

Matt: Removed "Back to the Guide" as I'm moving things around

2019-08-10T07:27:07Z

Removed "Back to the Guide" as I'm moving things around

Matt: /* Why Use Static Data? */

2018-11-13T02:31:22Z

‎Why Use Static Data?

Matt: Removed sentence containing 'jillions'

2018-11-13T02:30:09Z

Removed sentence containing 'jillions'

JavaJones at 02:43, 16 January 2013

2013-01-16T02:43:04Z

Jo at 02:39, 16 January 2013

2013-01-16T02:39:14Z

JavaJones: /* Why Use Static Data? */

2013-01-16T02:06:09Z

‎Why Use Static Data?

JavaJones: /* More Examples of Procedurals in TG */

2013-01-16T02:01:05Z

‎More Examples of Procedurals in TG

JavaJones: /* Case Study: Procedural vs Static - Fractal Terrain vs Heightfield */

2013-01-16T01:58:17Z

‎Case Study: Procedural vs Static - Fractal Terrain vs Heightfield

JavaJones at 01:46, 16 January 2013

2013-01-16T01:46:37Z

Jo at 22:15, 15 January 2013

2013-01-15T22:15:26Z

← Older revision		Revision as of 07:27, 10 August 2019
Line 70:		Line 70:

	Even when algorithms are known in general it can still be tricky. The best example of this is animation curves. Many applications use the same type of curves for animation. However unless the precise algorithm is known it's difficult to exactly reproduce the curve. This might be a problem if you were trying to match a camera move from TG with a camera move in another application. Although the curves might be roughly the same shape, minor differences could cause jitter or shake in the results. For this reason we suggest that animation curves are baked on import or export. Baking is a process where a key frame is placed at every frame. This effectively turns the procedural curve into a static one.		Even when algorithms are known in general it can still be tricky. The best example of this is animation curves. Many applications use the same type of curves for animation. However unless the precise algorithm is known it's difficult to exactly reproduce the curve. This might be a problem if you were trying to match a camera move from TG with a camera move in another application. Although the curves might be roughly the same shape, minor differences could cause jitter or shake in the results. For this reason we suggest that animation curves are baked on import or export. Baking is a process where a key frame is placed at every frame. This effectively turns the procedural curve into a static one.
−
−
−	~~[[Terragen_2_User_Guide_Part_2:_Fundamental_Rendering_and_Shader_Concepts\|Back to the Guide]]~~

@@ Line 52: / Line 52: @@
 If procedural data is so great then why do we use static data? In many situations static data is just what is needed. The discussion of heightfields above is one example of that. Another obvious example is polygonal 3D models. Of course in many cases an image is exactly what you need for texturing or masking. A combination of static and procedural data is often the best way to achieve the results you want.
-It's possible to use procedural data to improve static data. A good example of this is adding extra detail to heightfields using fractals. TG does this by default in the [[Heightfield Shader]] node. The shader can add extra small scale fractal detail which helps to make up for the limited resolution of the underlying heightfield. Of course the extra detail is "fake" but in most cases this doesn't matter. Here's an example of a heightfield with and without added fractal detail:<br />
+It's possible to use procedural data to improve static data. A good example of this is adding extra detail to heightfields using fractals. TG does this by default in the [[Heightfield Shader]] node. The shader can add extra small scale fractal detail which helps to make up for the limited resolution of the underlying heightfield. Of course the extra detail is "fake" but in many cases this doesn't matter. Here's an example of a heightfield with and without added fractal detail:<br />
 <center>

@@ Line 19: / Line 19: @@
 The second big difference between a procedural terrain and a heightfield is resolution, or detail. Once again, the amount of detail in a procedural terrain is theoretically infinite. There some practical limits to the detail. However the fact remains that you can zoom in very close to a procedural terrain and still see fine detail. By contrast a heightfield typically has a much coarser fixed resolution. The height measurements are in a fixed grid. A common size for this grid is 10m. That essentially means that there is no further detail in the terrain when you are looking at distances less than 10m apart. The procedural terrain might have detail down to the sub-millimetre level.
-Procedural terrains can be stored much more efficiently. The shape of terrain is based on a mathematical formula and a set of numbers which define some of the characteristics of the terrain. When you save a project or clip with a procedural terrain those values take up very little space in a file. In contrast a heightfield will take up much, much more space. A procedural terrain covering a whole planet can take less than a kilobyte. Heightfields covering an entire planet, such as the Mars MOLA dataset, can run into the gigabytes and it's still only accurate to the resolution of the heightfields. In non-scientific terms, heightfields generally consist of several jillion times more data.
+Procedural terrains can be stored much more efficiently. The shape of terrain is based on a mathematical formula and a set of numbers which define some of the characteristics of the terrain. When you save a project or clip with a procedural terrain those values take up very little space in a file. In contrast a heightfield will take up much, much more space. A procedural terrain covering a whole planet can take less than a kilobyte. Heightfields covering an entire planet, such as the Mars MOLA dataset, can run into the gigabytes and it's still only accurate to the resolution of the heightfields, which may not be enough.
 Another important difference is that heightfields can't have overhangs or caves. Overhangs in particular are often found in natural terrain, and may be highly desirable in unnatural terrains too. These sorts of features are no problem for procedural terrains in TG. Actually creating caves is not the easiest thing in TG, but this is more down to tools rather than limitations in capability.

@@ Line 11: / Line 11: @@
 ===Case Study: Procedural vs Static - Fractal Terrain vs Heightfield===
-Let's look at the differences between a procedural terrain and a heightfield based terrain. An example of a procedural terrain could be a [[Power Fractal Shader v3|Power Fractal]] or an [[Alpine Fractal Shader|Alpine Fractal]] terrain. Both of these are based on fractals. You can create one of these terrains using the "Add Terrain" button above the Terrain Node List.
+Let's look at the differences between a procedural terrain and a heightfield based terrain. An example of a procedural terrain could be a [[Power Fractal Shader v3|Power Fractal]] or an [[Alpine Fractal Shader v2|Alpine Fractal]] terrain. Both of these are based on fractals. You can create one of these terrains using the "Add Terrain" button above the Terrain Node List.
 The default TG project is set up with a heightfield ready to be generated. As well as generating heightfields TG can also read them from various sorts of files.

@@ Line 67: / Line 67: @@
 Another potential weakness of procedural data is the fact it's based on algorithms. This can be tricky when it comes to import and export. A prime example of this is procedural shaders. Many rendering applications support procedural shaders however it's not very common to have import/export of shaders between applications. This is because each application doesn't know the precise shading algorithms of the other applications. Without knowing that, one application is not able to recreate the results of another application.
-An good example of this is terrains. TG supports export of terrains but only as static data. You can either export the terrain as a heightfield or use a micro exporter to export rendered terrain as a polygon mesh. Another application wouldn't be able to recreate procedural terrains from TG because it doesn't know the algorithm TG uses to generate the terrain.
+One more example of this is terrains. TG supports export of terrains but only as static data. You can either export the terrain as a heightfield or use a micro exporter to export rendered terrain as a polygon mesh. Another application wouldn't be able to recreate procedural terrains from TG because it doesn't know the algorithm TG uses to generate the terrain.
 Even when algorithms are known in general it can still be tricky. The best example of this is animation curves. Many applications use the same type of curves for animation. However unless the precise algorithm is known it's difficult to exactly reproduce the curve. This might be a problem if you were trying to match a camera move from TG with a camera move in another application. Although the curves might be roughly the same shape, minor differences could cause jitter or shake in the results. For this reason we suggest that animation curves are baked on import or export. Baking is a process where a key frame is placed at every frame. This effectively turns the procedural curve into a static one.

@@ Line 63: / Line 63: @@
 You can see the extra detail makes quite a difference. The addition of extra detail is not limited to small scale features. You can easily create large procedural features on heightfields as well.
-One of the strengths of procedural data can also be a weakness. Generating procedural data can be computationally intensive. In some cases it may before efficient to use static data rather than procedural data. An example of this might be a mask made up of many procedural elements. If it was slow to compute and resolution wasn't much of an issue it could be better to paint the mask in an image editor and use the static image as the mask. Similarly a procedural terrain could be slow to calculate. There might be an advantage in saving the terrain as a heightfield, although of course you would need to take into consideration the limitations of heightfields, such as the lack of overhangs. In these kinds of situations you are making a trade-off between computation time and data size. An image might work as a mask and be faster to compute but it could take a lot of space on disk and/or in memory while rendering.
+One of the strengths of procedural data can also be a weakness. Generating procedural data can be computationally intensive. In some cases it may be more efficient to use static data rather than procedural data. An example of this might be a mask made up of many procedural elements. If it was slow to compute and resolution wasn't much of an issue it could be better to paint the mask in an image editor and use the static image as the mask. Similarly a procedural terrain could be slow to calculate. There might be an advantage in saving the terrain as a heightfield, although of course you would need to take into consideration the limitations of heightfields, such as the lack of overhangs. In these kinds of situations you are making a trade-off between computation time and data size. An image might work as a mask and be faster to compute but it could take a lot of space on disk and/or in memory while rendering.
-Another potential weakness of procedural data is the fact it's based on algorithms. This can be tricky when it comes to import and export. A prime example of this is procedural shaders. Many rendering applications support procedural shaders however it's not very common to have import/export of shaders between applications. This is because each application doesn't know the precise shading algorithms of the other applications. Without knowing that one application is not able to recreate the results of another application.
+Another potential weakness of procedural data is the fact it's based on algorithms. This can be tricky when it comes to import and export. A prime example of this is procedural shaders. Many rendering applications support procedural shaders however it's not very common to have import/export of shaders between applications. This is because each application doesn't know the precise shading algorithms of the other applications. Without knowing that, one application is not able to recreate the results of another application.
-Another example of this is terrains. TG supports export of terrains but only as static data. You can either export the terrain as a heightfield or use a micro exporter to export rendered terrain as a polygon mesh. Another application wouldn't be able to recreate procedural terrains from TG because it doesn't know the algorithm TG uses to generate the terrain.
+An good example of this is terrains. TG supports export of terrains but only as static data. You can either export the terrain as a heightfield or use a micro exporter to export rendered terrain as a polygon mesh. Another application wouldn't be able to recreate procedural terrains from TG because it doesn't know the algorithm TG uses to generate the terrain.
-Even when algorithms are known in general it can still be tricky. The best example of this is animation curves. Many applications use the same type of curves for animation. However unless the precise algorithm is known it's difficult to exactly reproduce the curve. This might be a problem if you were trying to match a camera move from TG with a camera move in another application. Although the curves might be roughly the same shape minor differences could cause jitter or shake in the results. For this reason we suggest that animation curves are baked on import or export. Baking is a process where a key frame is placed at every frame. This effectively turns the procedural curve into a static one.
+Even when algorithms are known in general it can still be tricky. The best example of this is animation curves. Many applications use the same type of curves for animation. However unless the precise algorithm is known it's difficult to exactly reproduce the curve. This might be a problem if you were trying to match a camera move from TG with a camera move in another application. Although the curves might be roughly the same shape, minor differences could cause jitter or shake in the results. For this reason we suggest that animation curves are baked on import or export. Baking is a process where a key frame is placed at every frame. This effectively turns the procedural curve into a static one.
 [[Terragen_2_User_Guide_Part_2:_Fundamental_Rendering_and_Shader_Concepts|Back to the Guide]]

@@ Line 26: / Line 26: @@
 ===More Examples of Procedurals in TG===
-Here's some other examples of procedural data in TG:
+Here are some other examples of procedural data in TG:
 <ul>
 <li>
 <u>Shaders</u><br />
-Many shaders are procedural. One example is the [[Simple Shape Shader]]. Although this creates basic shapes which could also be done with image maps using procedural generation means you can scale and rotate the shapes without edges becoming blurry or aliased.
+Many shaders are procedural. One example is the [[Simple Shape Shader]]. Although this creates basic shapes which could also be done with image maps, using procedural generation means you can scale and rotate the shapes without edges becoming blurry or aliased.
 </li><li>
 <u>Populators</u><br />

@@ Line 6: / Line 6: @@
 A key concept of procedural data is "data amplification". The idea is that a little bit of data can be used to generate a lot of data. This is a big part of the reason TG project files are so small in size. Only small amounts of data need to be stored in the file to generate the masses of data required for a visually complex scene.
-Another key concept is that the procedures used to generate data are "deterministic". This means that if you use the same starting values you get the same results. This is the reason you can load a saved project that uses prodecural data and the scene looks the same as when you created it.
+Another key concept is that the procedures used to generate data are "deterministic". This means that if you use the same starting values you get the same results. This is the reason you can load a saved project that uses procedural data and the scene looks the same as when you created it.
 The "opposite" of procedural data is what you might call static data. Static data is precalculated, generated entirely before being used. Some examples of static data used by TG are polygonal objects (usually imported), heightfields and images used as masks and textures.
@@ Line 30: / Line 30: @@
 <li>
 <u>Shaders</u><br />
-Many shaders are prodecural. One example is the [[Simple Shape Shader]]. Although this creates basic shapes which could also be done with image maps using procedural generation means you can scale and rotate the shapes without edges becoming blurry or aliased.
+Many shaders are procedural. One example is the [[Simple Shape Shader]]. Although this creates basic shapes which could also be done with image maps using procedural generation means you can scale and rotate the shapes without edges becoming blurry or aliased.
 </li><li>
 <u>Populators</u><br />