force use of pandoc version >= 3.1.12.2
The `bin/pandoc-wrapper.sh` tool will verify that the ssytem has a recent enough version of `pandoc(1)`. We explain why we insist on `pandoc(1)`. version >= 3.1.12.2 in comments where the $PANDOC_MIN_VERSION is set. Added `--wrap=preserve` as a default argument to `pandoc(1)`. While this change will impact every HTML file generated, we believe this will improve the ability of someone to look at the generated HTML and correlate with the original markdown. Changed `bin/pandoc-wrapper.sh` VERSION from "1.4.2 2024-03-17" to "1.4.3 2024-03-18". Performed `make www` to achieve all of the above and to generate HTML using the new `--wrap=preserve` `pandoc(1)` mode.
This commit is contained in:
Landon Curt Noll committed
1 parent
9eb7a54e9f
commit
b0b212acb1
402 files changed
+37061
-55132
No files matched your search
+137
-178
@@ -122,8 +122,7 @@
|
||||
|
||||
<h1 id="scene-format-documentation">Scene format documentation</h1>
|
||||
<p>The file must be encoded in UTF-8 as the BOF marker indicates.</p>
|
||||
<p>You can directly feed it to the renderer. If you’re wondering about
|
||||
what the following code block does, that’s why:)</p>
|
||||
<p>You can directly feed it to the renderer. If you’re wondering about what the following code block does, that’s why:)</p>
|
||||
<pre><code>@|?|?z#
|
||||
@|||?z&
|
||||
>?Sedvf
|
||||
@@ -157,38 +156,31 @@ ZnY|{|e
|
||||
kkdr\{\{\%
|
||||
lkdr\{\{></code></pre>
|
||||
<h2 id="basic-structure">Basic structure</h2>
|
||||
<p>A scene file begins with arbitrary binary data, followed by several
|
||||
shader functions.</p>
|
||||
<p>Shader functions are declared using a one-character name followed by
|
||||
a <code>]</code> character. There are some special function names, which
|
||||
will be explained below.</p>
|
||||
<p>The language used to write shader functions is very simple.
|
||||
Basically, you write a sequence of assignment statements like this:</p>
|
||||
<p>A scene file begins with arbitrary binary data, followed by several shader
|
||||
functions.</p>
|
||||
<p>Shader functions are declared using a one-character name followed by a <code>]</code>
|
||||
character. There are some special function names, which will be explained below.</p>
|
||||
<p>The language used to write shader functions is very simple. Basically, you write
|
||||
a sequence of assignment statements like this:</p>
|
||||
<pre><code>A=A+D
|
||||
B=B+E</code></pre>
|
||||
<p>Namely, you write a one-character variable name, an equal sign
|
||||
(<code>=</code>), followed by an expression (made of operators and
|
||||
one-character variable names, of course).</p>
|
||||
<p>Namely, you write a one-character variable name, an equal sign (<code>=</code>), followed
|
||||
by an expression (made of operators and one-character variable names, of
|
||||
course).</p>
|
||||
<h2 id="expressions">Expressions</h2>
|
||||
<p>The shader language supports seven operators, listed highest priority
|
||||
first:</p>
|
||||
<p>The shader language supports seven operators, listed highest priority first:</p>
|
||||
<pre><code>*/+-<#:</code></pre>
|
||||
<p><code>*/+-<</code> each mean what they mean in C, but the priority
|
||||
part is a bit different. Basically, <code>*</code> has higher priority
|
||||
than <code>/</code>, so <code>A/4*4</code> actually computes
|
||||
<code>A/(4*4)</code>. And you can’t write <code>(A/4)*4</code> –
|
||||
brackets are not supported. As an advice, keep your expressions simple
|
||||
:) If you really needs to write something like <code>C=(A/4)*4</code>,
|
||||
write instead:</p>
|
||||
<p><code>*/+-<</code> each mean what they mean in C, but the priority part is a bit different.
|
||||
Basically, <code>*</code> has higher priority than <code>/</code>, so <code>A/4*4</code> actually computes
|
||||
<code>A/(4*4)</code>. And you can’t write <code>(A/4)*4</code> – brackets are not supported. As an
|
||||
advice, keep your expressions simple :) If you really needs to write something
|
||||
like <code>C=(A/4)*4</code>, write instead:</p>
|
||||
<pre><code>B=A/4+
|
||||
C=B*4</code></pre>
|
||||
<p>The <code>#</code> operator acts somewhat like the C <code>?:</code>.
|
||||
It returns one of its two operands based on, what else, the value of
|
||||
variable <code>#</code>. When <code>#</code> is true, <code>#</code>
|
||||
<p>The <code>#</code> operator acts somewhat like the C <code>?:</code>. It returns one of its two
|
||||
operands based on, what else, the value of variable <code>#</code>. When <code>#</code> is true, <code>#</code>
|
||||
returns its second operand.</p>
|
||||
<p>The <code>:</code> operator calls built-in functions. The first
|
||||
operand is the function id and the second is the parameter. Here is a
|
||||
list of functions:</p>
|
||||
<p>The <code>:</code> operator calls built-in functions. The first operand is the function id and the second is the parameter. Here is a list of functions:</p>
|
||||
<pre><code>0:x = the x-th byte of the scene file
|
||||
1:x = sin(x*PI)
|
||||
2:x = atan2(x,#)/PI
|
||||
@@ -197,43 +189,36 @@ list of functions:</p>
|
||||
5:x = the next number in the (allegedly random) number sequence, can't be called in volume shaders
|
||||
6:x = value of the variable (char)(120+x)
|
||||
7:x = write #'s value to the variable (char)(120+x)</code></pre>
|
||||
<p>Contrary to popular belief, the language itself doesn’t support
|
||||
numerical constants. Any character sitting between operators is a
|
||||
variable. When you see 1/2, it’s in fact dividing the variable 1’s value
|
||||
by the variable 2’s value. For everyone’s convenience, though, in the
|
||||
beginning every variable is initialized to its ASCII code minus 48. As
|
||||
long as you don’t write something like <code>3=1+1</code>, you can use
|
||||
single digit numbers as, well, single digit numbers. If you need
|
||||
something like <code>1920</code> or <code>0.73</code>, you need to
|
||||
compute it yourself. And yes, all variables store floating point
|
||||
values.</p>
|
||||
<p>If a character appears as the first character of any
|
||||
<code>argv</code>, it goes to zero. This includes the scene filename. If
|
||||
you name your scene <code>1.scene</code>, well, good luck with
|
||||
<code>1=0</code>!</p>
|
||||
<p>You can terminate a statement using any character that isn’t an
|
||||
operator, be it <code>\n</code> or <code>;</code>. But you must put in
|
||||
one and only one character. Put in two (e.g. the Windows
|
||||
<code>\r\n</code>), and it terminates your function. Also, the first
|
||||
statement must begin immediately after <code>]</code>.</p>
|
||||
<p>When a function terminates, the interpreter calls the next function
|
||||
specified by variable <code>R</code>. If you want to call function
|
||||
<code>n</code>, just write somewhere:</p>
|
||||
<p>Contrary to popular belief, the language itself doesn’t support numerical
|
||||
constants. Any character sitting between operators is a variable. When you see
|
||||
1/2, it’s in fact dividing the variable 1’s value by the variable 2’s value. For
|
||||
everyone’s convenience, though, in the beginning every variable is initialized
|
||||
to its ASCII code minus 48. As long as you don’t write something like <code>3=1+1</code>,
|
||||
you can use single digit numbers as, well, single digit numbers. If you need
|
||||
something like <code>1920</code> or <code>0.73</code>, you need to compute it yourself. And yes, all
|
||||
variables store floating point values.</p>
|
||||
<p>If a character appears as the first character of any <code>argv</code>, it goes to zero.
|
||||
This includes the scene filename. If you name your scene <code>1.scene</code>, well, good
|
||||
luck with <code>1=0</code>!</p>
|
||||
<p>You can terminate a statement using any character that isn’t an operator, be it
|
||||
<code>\n</code> or <code>;</code>. But you must put in one and only one character. Put in two (e.g.
|
||||
the Windows <code>\r\n</code>), and it terminates your function. Also, the first statement
|
||||
must begin immediately after <code>]</code>.</p>
|
||||
<p>When a function terminates, the interpreter calls the next function specified by
|
||||
variable <code>R</code>. If you want to call function <code>n</code>, just write somewhere:</p>
|
||||
<pre><code>R=n</code></pre>
|
||||
<p>providing you have left <code>n</code> at its initial value. If you
|
||||
want to actually return to the renderer, put in <code>R=0</code>.</p>
|
||||
<p>As you may have noticed, you can put in all kinds of stuff between
|
||||
functions, like this comment.</p>
|
||||
<h2 id="how-the-____-do-i-render-an-image-with-shaders">How the ____ do
|
||||
I render an image with shaders?</h2>
|
||||
<p>Basically, you define a geometry using volume shaders, define a
|
||||
camera using a camera shader, and define light sources and surface
|
||||
reflectance properties using material shaders.</p>
|
||||
<p>providing you have left <code>n</code> at its initial value. If you want to actually return
|
||||
to the renderer, put in <code>R=0</code>.</p>
|
||||
<p>As you may have noticed, you can put in all kinds of stuff between functions,
|
||||
like this comment.</p>
|
||||
<h2 id="how-the-____-do-i-render-an-image-with-shaders">How the ____ do I render an image with shaders?</h2>
|
||||
<p>Basically, you define a geometry using volume shaders, define a camera using a
|
||||
camera shader, and define light sources and surface reflectance properties using
|
||||
material shaders.</p>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td style="text-align: left;">Continue to the comments before function
|
||||
A</td>
|
||||
<td style="text-align: left;">Continue to the comments before function A</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
@@ -259,43 +244,37 @@ R=0#n</code></pre>
|
||||
H -- Image height, in pixels
|
||||
I -- Perturbation probability
|
||||
J -- Camera ray stratification probability</code></pre>
|
||||
<p>If you have used a MLT renderer before, you probably know what
|
||||
<code>I</code> and <code>J</code> does. If you don’t, well, use the same
|
||||
value as the default scene. Everything converges just fine under
|
||||
suboptimal settings, just a little slower. Generally, use a higher value
|
||||
for <code>I</code> if your scene is primarily illuminated by some
|
||||
<p>If you have used a MLT renderer before, you probably know what <code>I</code> and <code>J</code> does.
|
||||
If you don’t, well, use the same value as the default scene. Everything
|
||||
converges just fine under suboptimal settings, just a little slower. Generally,
|
||||
use a higher value for <code>I</code> if your scene is primarily illuminated by some
|
||||
indirect source.</p>
|
||||
<p><code>A</code> also serves as the geometry shader for volume 0. The
|
||||
scene geometry is made of up to 32 volumes, each with 64x64x64 cells.
|
||||
The volume 0 is the ‘top level’ volume where the camera goes. Each cell
|
||||
of a volume can be empty, filled with a material, or another volume. The
|
||||
roundish characters in <a
|
||||
href="../old_default.scene">old_default.scene</a> and the carpet on the
|
||||
floor in this file are examples where a cell is defined to another
|
||||
volume. Materials will be explained later.</p>
|
||||
<p>The volume shader for the i-th volume is named as the (i+1)-th
|
||||
capital letter. Each volume shader is invoked once for each cell. The
|
||||
cell coordinates (0..63) are given as inputs in variable
|
||||
<code>x</code>,<code>y</code>,<code>z</code>, and you’re supposed to
|
||||
return the cell content in variable <code>C</code>. To fill it with
|
||||
material <code>i</code>, return <code>64+i</code> in <code>C</code>. To
|
||||
fill it with volume <code>i</code>, well, return <code>i</code>. To
|
||||
leave it empty, return <code>C=0</code>.</p>
|
||||
<p>Before starting to build a scene, it’s better to have a draft sketch
|
||||
handy first. Something like <img src="draft.png" alt="Draft sketch" />.
|
||||
Sometimes it’s hard to imagine where something should go without the
|
||||
sketch. And you don’t have to stick to your sketch :)</p>
|
||||
<p>What motivated my default scene: it was the full moon’s day (a
|
||||
national holiday) in China and my parents were planning to renovate
|
||||
their apartment. I rendered the image to tell my mom how ridiculous her
|
||||
starry-sky wall paper would look like if she used it on every single
|
||||
wall. She ends up using it on just one wall, the one facing my bed, to
|
||||
thank me for the effort.</p>
|
||||
<p><code>A</code> also serves as the geometry shader for volume 0. The scene geometry is made
|
||||
of up to 32 volumes, each with 64x64x64 cells. The volume 0 is the ‘top level’
|
||||
volume where the camera goes. Each cell of a volume can be empty, filled with a
|
||||
material, or another volume. The roundish characters in
|
||||
<a href="../old_default.scene">old_default.scene</a> and the carpet on the floor in this
|
||||
file are examples where a cell is defined to another volume. Materials will be
|
||||
explained later.</p>
|
||||
<p>The volume shader for the i-th volume is named as the (i+1)-th capital letter.
|
||||
Each volume shader is invoked once for each cell. The cell coordinates (0..63)
|
||||
are given as inputs in variable <code>x</code>,<code>y</code>,<code>z</code>, and you’re supposed to return the
|
||||
cell content in variable <code>C</code>. To fill it with material <code>i</code>, return <code>64+i</code> in
|
||||
<code>C</code>. To fill it with volume <code>i</code>, well, return <code>i</code>. To leave it empty, return
|
||||
<code>C=0</code>.</p>
|
||||
<p>Before starting to build a scene, it’s better to have a draft sketch handy
|
||||
first. Something like <img src="draft.png" alt="Draft sketch" />. Sometimes it’s hard to
|
||||
imagine where something should go without the sketch. And you don’t have to
|
||||
stick to your sketch :)</p>
|
||||
<p>What motivated my default scene: it was the full moon’s day (a national holiday)
|
||||
in China and my parents were planning to renovate their apartment. I rendered
|
||||
the image to tell my mom how ridiculous her starry-sky wall paper would look
|
||||
like if she used it on every single wall. She ends up using it on just one wall,
|
||||
the one facing my bed, to thank me for the effort.</p>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td style="text-align: left;">Continue to the comments before function
|
||||
a</td>
|
||||
<td style="text-align: left;">Continue to the comments before function a</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
@@ -311,39 +290,32 @@ J=1/2+
|
||||
C=p+1+
|
||||
U=w+w+w</code></pre>
|
||||
<hr />
|
||||
<p>The function <code>a</code> is the camera shader, which, well,
|
||||
generates the camera ray. It’s supposed to return the ray in variables
|
||||
<code>UVWXYZ</code> and <code>ABCDEF</code> (that may sound like a lot
|
||||
of variables, but it really isn’t that much).</p>
|
||||
<p>Here comes some subtlety of <code>PSSMLT</code> (Primary Sample Space
|
||||
Metropolis Light Transport, or Kelemen-style MLT). Basically, a
|
||||
<code>PSSMLT</code> renderer gives you an (allegedly random) number
|
||||
sequence, and you compute a color out of it. This is usually done by
|
||||
generating and tracing rays out of those random numbers. The renderer
|
||||
would assemble the colors into an image.</p>
|
||||
<p>Remember the function <code>5</code>? Here it comes. The first two
|
||||
“random” numbers have special meaning and must specify a point on the
|
||||
image plane <code>[0,1)x[0,1)</code>. You’re supposed to transform the
|
||||
image plane to the 3D space, choose a point for the camera, and shoot a
|
||||
ray from the camera point to the image plane point, see <img
|
||||
src="camera.png" alt="Camera convention" />. The camera point goes to
|
||||
<code>(U,V,W)</code>, and the ray direction vector (image plane point -
|
||||
camera point) is <code>(X,Y,Z)</code>. For the coordinate space, volume
|
||||
0 is scaled up 64x here to <code>(0,0,0)-(4096,4096,4096)</code>.</p>
|
||||
<p>For a basic camera shader example, check <a
|
||||
href="../otherroom.scene">otherroom.scene</a>.</p>
|
||||
<p>If any ray goes out of volume 0, the renderer crashes. Make sure it
|
||||
doesn’t happen. Wall up everything.</p>
|
||||
<p>Variables <code>ABCDEF</code> control the color returned from the
|
||||
ray. They will be explained in the material shaders part. For now, just
|
||||
put in:</p>
|
||||
<p>The function <code>a</code> is the camera shader, which, well, generates the camera ray.
|
||||
It’s supposed to return the ray in variables <code>UVWXYZ</code> and <code>ABCDEF</code> (that may
|
||||
sound like a lot of variables, but it really isn’t that much).</p>
|
||||
<p>Here comes some subtlety of <code>PSSMLT</code> (Primary Sample Space Metropolis Light
|
||||
Transport, or Kelemen-style MLT). Basically, a <code>PSSMLT</code> renderer gives you an
|
||||
(allegedly random) number sequence, and you compute a color out of it. This is
|
||||
usually done by generating and tracing rays out of those random numbers. The
|
||||
renderer would assemble the colors into an image.</p>
|
||||
<p>Remember the function <code>5</code>? Here it comes. The first two “random” numbers have
|
||||
special meaning and must specify a point on the image plane <code>[0,1)x[0,1)</code>.
|
||||
You’re supposed to transform the image plane to the 3D space, choose a point for
|
||||
the camera, and shoot a ray from the camera point to the image plane point, see
|
||||
<img src="camera.png" alt="Camera convention" />. The camera point goes to <code>(U,V,W)</code>, and the
|
||||
ray direction vector (image plane point - camera point) is <code>(X,Y,Z)</code>. For the
|
||||
coordinate space, volume 0 is scaled up 64x here to <code>(0,0,0)-(4096,4096,4096)</code>.</p>
|
||||
<p>For a basic camera shader example, check <a href="../otherroom.scene">otherroom.scene</a>.</p>
|
||||
<p>If any ray goes out of volume 0, the renderer crashes. Make sure it doesn’t
|
||||
happen. Wall up everything.</p>
|
||||
<p>Variables <code>ABCDEF</code> control the color returned from the ray. They will be
|
||||
explained in the material shaders part. For now, just put in:</p>
|
||||
<pre><code>A=0;B=0;C=0
|
||||
D=1;E=1;F=1</code></pre>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td style="text-align: left;">Continue to the comments before function
|
||||
1</td>
|
||||
<td style="text-align: left;">Continue to the comments before function 1</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
@@ -371,39 +343,32 @@ W=p*8+
|
||||
A=0;B=0;C=0+
|
||||
D=1;E=1;F=1</code></pre>
|
||||
<hr />
|
||||
<p>The numbered functions define materials, i.e., surface reflectance
|
||||
properties. As the name suggests, the shader simulates ray-surface
|
||||
interaction. It’s done by updating <code>UVWXYZABCDEF</code>, of
|
||||
course.</p>
|
||||
<p><code>ABCDEF</code> define colors. <code>(A,B,C)</code> is the RGB
|
||||
irradiance ultimately returned to the renderer, and <code>(D,E,F)</code>
|
||||
maintain the cumulative RGB reflectance of the current ray path. This
|
||||
may sound confusing, but basically, if the surface is a light source,
|
||||
you accumulate the current path reflectance <code>(D,E,F)</code>,
|
||||
multiplied by the light strength, to <code>(A,B,C)</code>. See shader 6
|
||||
for an example.</p>
|
||||
<p>If you want a colored surface, use its color to modulate
|
||||
<code>(D,E,F)</code>, i.e. <code>D=D*red;E=E*green;F=F*blue</code>, easy
|
||||
as that. To get some texturing, compute the color procedurally or look
|
||||
up a binary table.</p>
|
||||
<p>There’s something subtle about colors. To go along with the trend,
|
||||
the renderer follows the practice of linear rendering with a gamma of
|
||||
<code>2</code>. Stripping the fancy jargon, that basically means after
|
||||
picking a color in your favorite image editing program, you need to
|
||||
convert the RGB values from 0..255 to 0..1, and then put here its
|
||||
<em>square</em>. Only after squaring you get your real, lively color in
|
||||
the output image, as opposed to something dull and gray. You need to do
|
||||
the same if you use a RGB texture. And yes, that is the what the second
|
||||
<code>sqrt(3)</code> in <a href="../a.c">a.c</a> is for.</p>
|
||||
<p>Going beyond colors, to define a shiny or dull surface one needs more
|
||||
maths, and optics. The jargon for this is <code>BRDF</code>
|
||||
(Bidirectional Reflectance Distribution Function) importance sampling.
|
||||
Let’s continue to function <code>o</code>.</p>
|
||||
<p>The numbered functions define materials, i.e., surface reflectance properties.
|
||||
As the name suggests, the shader simulates ray-surface interaction. It’s done by
|
||||
updating <code>UVWXYZABCDEF</code>, of course.</p>
|
||||
<p><code>ABCDEF</code> define colors. <code>(A,B,C)</code> is the RGB irradiance ultimately returned to
|
||||
the renderer, and <code>(D,E,F)</code> maintain the cumulative RGB reflectance of the
|
||||
current ray path. This may sound confusing, but basically, if the surface is a
|
||||
light source, you accumulate the current path reflectance <code>(D,E,F)</code>, multiplied
|
||||
by the light strength, to <code>(A,B,C)</code>. See shader 6 for an example.</p>
|
||||
<p>If you want a colored surface, use its color to modulate <code>(D,E,F)</code>, i.e.
|
||||
<code>D=D*red;E=E*green;F=F*blue</code>, easy as that. To get some texturing, compute the
|
||||
color procedurally or look up a binary table.</p>
|
||||
<p>There’s something subtle about colors. To go along with the trend, the renderer
|
||||
follows the practice of linear rendering with a gamma of <code>2</code>. Stripping the
|
||||
fancy jargon, that basically means after picking a color in your favorite image
|
||||
editing program, you need to convert the RGB values from 0..255 to 0..1, and
|
||||
then put here its <em>square</em>. Only after squaring you get your real, lively color
|
||||
in the output image, as opposed to something dull and gray. You need to do the
|
||||
same if you use a RGB texture. And yes, that is the what the second <code>sqrt(3)</code> in
|
||||
<a href="../a.c">a.c</a> is for.</p>
|
||||
<p>Going beyond colors, to define a shiny or dull surface one needs more maths, and
|
||||
optics. The jargon for this is <code>BRDF</code> (Bidirectional Reflectance Distribution
|
||||
Function) importance sampling. Let’s continue to function <code>o</code>.</p>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
<td style="text-align: left;">Continue to the comments before function
|
||||
o</td>
|
||||
<td style="text-align: left;">Continue to the comments before function o</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
@@ -434,34 +399,28 @@ E=E*4/7+
|
||||
d=I#2/5+
|
||||
F=F*d</code></pre>
|
||||
<hr />
|
||||
<p>Function <code>o</code> defines a diffuse (that is, dull) surface. To
|
||||
define reflectance properties like this, one needs to sample an outgoing
|
||||
ray direction, based on the incoming direction and the surface normal.
|
||||
It’s called importance sampling, because here the probability of each
|
||||
outgoing direction has to be proportional to the reflected light
|
||||
strength (i.e., the <code>BRDF</code>) on that direction. For a diffuse
|
||||
surface, sample the upper hemisphere with a probability proportional to
|
||||
the cosine of the outgoing angle, see <img src="cosine.png"
|
||||
alt="Cosine sampling" />.</p>
|
||||
<p>The incoming direction is in <code>(X,Y,Z)</code> and the hit point
|
||||
is <code>(U,V,W)</code>. The outgoing direction is returned in, where
|
||||
else, <code>(X,Y,Z)</code>.</p>
|
||||
<p>The surface normal is provided in variables <code>S</code> and
|
||||
<code>T</code>. Since the geometry is defined as a bunch of cube-shaped
|
||||
cells, there are only 6 possible normals:
|
||||
<code>(±1,0,0) (0,±1,0) (0,0,±1)</code>. Here <code>S</code> is the sign
|
||||
and <code>T</code> is the dimension. If you get <code>S=-1</code> and
|
||||
<code>T=1</code>, the normal is <code>(0,-1,0)</code>.</p>
|
||||
<p>If you don’t want to redo all the math yourself… this file provides a
|
||||
few simple shader functions:</p>
|
||||
<p>Function <code>o</code> defines a diffuse (that is, dull) surface. To define reflectance
|
||||
properties like this, one needs to sample an outgoing ray direction, based on
|
||||
the incoming direction and the surface normal. It’s called importance sampling,
|
||||
because here the probability of each outgoing direction has to be proportional
|
||||
to the reflected light strength (i.e., the <code>BRDF</code>) on that direction. For a
|
||||
diffuse surface, sample the upper hemisphere with a probability proportional to
|
||||
the cosine of the outgoing angle, see <img src="cosine.png" alt="Cosine sampling" />.</p>
|
||||
<p>The incoming direction is in <code>(X,Y,Z)</code> and the hit point is <code>(U,V,W)</code>. The
|
||||
outgoing direction is returned in, where else, <code>(X,Y,Z)</code>.</p>
|
||||
<p>The surface normal is provided in variables <code>S</code> and <code>T</code>. Since the geometry is
|
||||
defined as a bunch of cube-shaped cells, there are only 6 possible normals:
|
||||
<code>(±1,0,0) (0,±1,0) (0,0,±1)</code>. Here <code>S</code> is the sign and <code>T</code> is the dimension. If
|
||||
you get <code>S=-1</code> and <code>T=1</code>, the normal is <code>(0,-1,0)</code>.</p>
|
||||
<p>If you don’t want to redo all the math yourself… this file provides a few simple shader functions:</p>
|
||||
<pre><code>o -- Diffuse surface. Do the color thing your self and call R=o
|
||||
5 -- Perfect mirror.
|
||||
f -- Surface with a Fresnel term. Basically, it resembles a polished surface made from a dielectric material.</code></pre>
|
||||
<p>For something more complex like a fluffy carpet, well, you could use
|
||||
a volume to directly model the <a
|
||||
href="https://en.wikipedia.org/wiki/Mesoscopic_physics">mesoscopic</a>
|
||||
detail. Shader <code>D</code> in this file produces a bunch of dense,
|
||||
tiny spikes to simulate a fluffy appearance.</p>
|
||||
<p>For something more complex like a fluffy carpet, well, you could use a volume to
|
||||
directly model the
|
||||
<a href="https://en.wikipedia.org/wiki/Mesoscopic_physics">mesoscopic</a> detail. Shader
|
||||
<code>D</code> in this file produces a bunch of dense, tiny spikes to simulate a fluffy
|
||||
appearance.</p>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr class="odd">
|
||||
@@ -567,8 +526,8 @@ y=4:#/7+
|
||||
#=#-y*7+
|
||||
C=7#C</code></pre>
|
||||
<hr />
|
||||
<p>The last line, well, is the output filename. Just remember to throw
|
||||
in two <code>]</code>s and don’t put a newline after it.</p>
|
||||
<p>The last line, well, is the output filename. Just remember to throw in two <code>]</code>s
|
||||
and don’t put a newline after it.</p>
|
||||
<pre><code>]]example.ppm</code></pre>
|
||||
|
||||
<!-- END: this line ends content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||||
|
||||
+166
-236
@@ -130,8 +130,8 @@
|
||||
<h2 id="author"><a name="author"></a>Author:</h2>
|
||||
<ul>
|
||||
<li>Name: <a href="../../authors.html#Qiming_HOU">Qiming HOU</a><br>
|
||||
Location: <a href="../../location.html#CN">CN</a> - <em>People’s
|
||||
Republic of China</em> (<em>China</em>) <br><br></li>
|
||||
Location: <a href="../../location.html#CN">CN</a> - <em>People’s Republic of China</em> (<em>China</em>)
|
||||
<br><br></li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-author.sh -->
|
||||
@@ -144,166 +144,138 @@ Republic of China</em> (<em>China</em>) <br><br></li>
|
||||
<h3 id="bugs-and-misfeatures">Bugs and (Mis)features:</h3>
|
||||
<p>The current status of this entry is:</p>
|
||||
<pre><code>STATUS: INABIAF - please **DO NOT** fix</code></pre>
|
||||
<p>For more detailed information see <a
|
||||
href="../../bugs.html#2013_hou">2013 hou bugs</a>.</p>
|
||||
<p>For more detailed information see <a href="../../bugs.html#2013_hou">2013 hou bugs</a>.</p>
|
||||
<h2 id="to-use">To use:</h2>
|
||||
<div class="sourceCode" id="cb3"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="ex">./hou</span> <span class="pp">[</span><span class="ss">scene</span><span class="pp">-</span><span class="ss">file</span><span class="pp">-</span><span class="ss">name</span><span class="pp">]</span> <span class="pp">[</span><span class="ss">options</span><span class="pp">]</span></span></code></pre></div>
|
||||
<p>Follow the instructions in <code>stdout</code>, preferably with an
|
||||
auto-refreshing PPM image viewer ready. Refresh the image every time the
|
||||
output refreshes, all effects should be more or less recognizable when
|
||||
you see 16.</p>
|
||||
<p>Follow the instructions in <code>stdout</code>, preferably with an auto-refreshing PPM
|
||||
image viewer ready. Refresh the image every time the output refreshes, all
|
||||
effects should be more or less recognizable when you see 16.</p>
|
||||
<h2 id="try">Try:</h2>
|
||||
<div class="sourceCode" id="cb4"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb4-1"><a href="#cb4-1" aria-hidden="true" tabindex="-1"></a><span class="ex">./try.sh</span></span></code></pre></div>
|
||||
<p>Try opening the file noted by the program then let the program run a
|
||||
while and every so often reopen the file, to see how it changes. The
|
||||
author suggests that you leave the program running overnight to see what
|
||||
happens. If however you do not have all night :-) then the following
|
||||
JPEG files should show you what happens with some of the invocations
|
||||
above:</p>
|
||||
<p>Try opening the file noted by the program then let the program run a while and
|
||||
every so often reopen the file, to see how it changes. The author suggests that
|
||||
you leave the program running overnight to see what happens. If however you do
|
||||
not have all night :-) then the following JPEG files should show you what
|
||||
happens with some of the invocations above:</p>
|
||||
<figure>
|
||||
<img src="luna.jpg" alt="./hou BIG - Luna" />
|
||||
<figcaption aria-hidden="true">./hou BIG - Luna</figcaption>
|
||||
</figure>
|
||||
<figure>
|
||||
<img src="old_default.jpg"
|
||||
alt="./hou old_default.scene - Old default" />
|
||||
<figcaption aria-hidden="true">./hou old_default.scene - Old
|
||||
default</figcaption>
|
||||
<img src="old_default.jpg" alt="./hou old_default.scene - Old default" />
|
||||
<figcaption aria-hidden="true">./hou old_default.scene - Old default</figcaption>
|
||||
</figure>
|
||||
<figure>
|
||||
<img src="otherroom.jpg" alt="./hou otherroom.scene - Other room" />
|
||||
<figcaption aria-hidden="true">./hou otherroom.scene - Other
|
||||
room</figcaption>
|
||||
<figcaption aria-hidden="true">./hou otherroom.scene - Other room</figcaption>
|
||||
</figure>
|
||||
<p>This program does not terminate by itself: you must kill
|
||||
<code>hou</code> (but not Qiming Hou :-) ) in order to end the
|
||||
program.</p>
|
||||
<p>This program does not terminate by itself: you must kill <code>hou</code> (but not Qiming
|
||||
Hou :-) ) in order to end the program.</p>
|
||||
<h2 id="judges-remarks">Judges’ remarks:</h2>
|
||||
<p>You could consider that this program violates the source code size
|
||||
limit. This is because the first compilation of this program is really
|
||||
just a decompressor to generate the real source code of the program.</p>
|
||||
<p>This program will loop infinitely while progressively refining a <a
|
||||
href="https://en.wikipedia.org/wiki/Ray_tracing_(graphics)">raytraced</a>
|
||||
image.</p>
|
||||
<p>NOTE: the author refers to <a href="a.c">a.c</a>, placed in a gzipped
|
||||
file <code>a.c.gz</code>. We do not include it but it can be generated
|
||||
like:</p>
|
||||
limit. This is because the first compilation of this program is
|
||||
really just a decompressor to generate the real source code of the
|
||||
program.</p>
|
||||
<p>This program will loop infinitely while progressively refining a
|
||||
<a href="https://en.wikipedia.org/wiki/Ray_tracing_(graphics)">raytraced</a> image.</p>
|
||||
<p>NOTE: the author refers to <a href="a.c">a.c</a>, placed in a gzipped file <code>a.c.gz</code>. We do not
|
||||
include it but it can be generated like:</p>
|
||||
<div class="sourceCode" id="cb5"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb5-1"><a href="#cb5-1" aria-hidden="true" tabindex="-1"></a><span class="fu">cc</span> <span class="at">-Wall</span> hou.c <span class="at">-o</span> hou <span class="at">-lm</span></span>
|
||||
<span id="cb5-2"><a href="#cb5-2" aria-hidden="true" tabindex="-1"></a><span class="ex">./hou</span> <span class="op">></span> a.c</span></code></pre></div>
|
||||
<p>but there is no need to do this as the Makefile takes care of it
|
||||
without even needing to create a temporary file.</p>
|
||||
<p>but there is no need to do this as the Makefile takes care of it without even
|
||||
needing to create a temporary file.</p>
|
||||
<h2 id="authors-remarks">Author’s remarks:</h2>
|
||||
<h3 id="using-hou">Using hou</h3>
|
||||
<p>This program is a programmable rendering engine with a built-in
|
||||
default scene. The standard command line is:</p>
|
||||
<p>This program is a programmable rendering engine with a built-in default scene.
|
||||
The standard command line is:</p>
|
||||
<div class="sourceCode" id="cb6"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb6-1"><a href="#cb6-1" aria-hidden="true" tabindex="-1"></a><span class="ex">./hou</span> <span class="pp">[</span><span class="ss">scene</span><span class="pp">-</span><span class="ss">file</span><span class="pp">-</span><span class="ss">name</span><span class="pp">]</span> <span class="pp">[</span><span class="ss">options</span><span class="pp">]</span></span></code></pre></div>
|
||||
<p>As <code>hou</code> runs, it writes a progressively refining image to
|
||||
a ppm file specified in the scene. The initialization may take a while,
|
||||
but once it’s done, a rough preview should be available in seconds.
|
||||
Leave <code>hou</code> running for the night, and you get a high quality
|
||||
result like the attached <code>*.jpg</code> files. Kill <code>hou</code>
|
||||
manually after you’re satisfied with the image quality.</p>
|
||||
<p>To save time and energy for the judges, rendered images for all
|
||||
provided scenes are provided as attached files.</p>
|
||||
<p>As <code>hou</code> runs, it writes a progressively refining image to a ppm file specified
|
||||
in the scene. The initialization may take a while, but once it’s done, a rough
|
||||
preview should be available in seconds. Leave <code>hou</code> running for the night, and you
|
||||
get a high quality result like the attached <code>*.jpg</code> files. Kill <code>hou</code> manually
|
||||
after you’re satisfied with the image quality.</p>
|
||||
<p>To save time and energy for the judges, rendered images for all provided scenes
|
||||
are provided as attached files.</p>
|
||||
<h3 id="features">Features</h3>
|
||||
<ul>
|
||||
<li>Fully programmable: Almost every stage of the renderer is
|
||||
programmable with a shader, i.e., a short script that does something
|
||||
rendering-related. In particular, each scene consists of one or more
|
||||
geometry shaders, a camera shader, and one or more material shaders.
|
||||
Shaders are written in an interpreted language that supports basic
|
||||
arithmetic, a few math functions, variables and procedural calls in the
|
||||
CPS (Continuation Passing Style).</li>
|
||||
<li>Fast preview: This renderer isn’t just a naive path tracer, it
|
||||
actually uses a modern global illumination algorithm which is robust
|
||||
against challenging scene configurations. You can mostly place light
|
||||
sources and specify surface properties as you please without worrying
|
||||
too much about the convergence speed; you always get a nice fast preview
|
||||
within one or two minutes. As proof, there is a comparison:
|
||||
<code>./hou otherroom.scene</code> gives a rough idea about the overall
|
||||
illumination at 16 samples per pixel (i.e., when the program prints 16),
|
||||
whereas the naive approach <code>./hou otherroom.scene NAIVE</code> only
|
||||
produces a mess of white dots.</li>
|
||||
<li>Rich visual effects: The algorithm samples all light path types so
|
||||
most physically based effects can be produced. The default scene
|
||||
demonstrates quite a few of them: reflection, area light, soft shadows,
|
||||
color bleeding, caustics, and depth-of-field blur. Of course, one can
|
||||
also get programmable-shading effects like procedural texturing and
|
||||
approximated Fresnel terms.</li>
|
||||
<li>Accelerated ray tracing: The ray tracing part uses an algorithm
|
||||
better than the brute-force intersection of everything. The renderer
|
||||
even builds an acceleration data structure! Despite the double precision
|
||||
and the single-threadedness, it still runs at about 0.5 million rays per
|
||||
second on the author’s machine.</li>
|
||||
<li>Pause and resume: Can’t run <code>./hou</code> overnight? No
|
||||
problem! You can kill and resume a rendering session whenever you want.
|
||||
The renderer automatically saves the progress every 16 samples and
|
||||
resumes where it’s left off when restarted. Also, each scene/parameter
|
||||
combination gets a different saved session so you don’t have to worry
|
||||
about conflicts.</li>
|
||||
<li>Fully programmable: Almost every stage of the renderer is programmable with
|
||||
a shader, i.e., a short script that does something rendering-related. In
|
||||
particular, each scene consists of one or more geometry shaders, a camera
|
||||
shader, and one or more material shaders. Shaders are written in an
|
||||
interpreted language that supports basic arithmetic, a few math functions,
|
||||
variables and procedural calls in the CPS (Continuation Passing Style).</li>
|
||||
<li>Fast preview: This renderer isn’t just a naive path tracer, it actually uses a
|
||||
modern global illumination algorithm which is robust against challenging scene
|
||||
configurations. You can mostly place light sources and specify surface
|
||||
properties as you please without worrying too much about the convergence speed;
|
||||
you always get a nice fast preview within one or two minutes. As proof, there
|
||||
is a comparison: <code>./hou otherroom.scene</code> gives a rough idea about the overall
|
||||
illumination at 16 samples per pixel (i.e., when the program prints 16), whereas
|
||||
the naive approach <code>./hou otherroom.scene NAIVE</code> only produces a mess of white
|
||||
dots.</li>
|
||||
<li>Rich visual effects: The algorithm samples all light path types so most
|
||||
physically based effects can be produced. The default scene demonstrates quite a
|
||||
few of them: reflection, area light, soft shadows, color bleeding, caustics, and
|
||||
depth-of-field blur. Of course, one can also get programmable-shading effects
|
||||
like procedural texturing and approximated Fresnel terms.</li>
|
||||
<li>Accelerated ray tracing: The ray tracing part uses an algorithm better than
|
||||
the brute-force intersection of everything. The renderer even builds an
|
||||
acceleration data structure! Despite the double precision and the
|
||||
single-threadedness, it still runs at about 0.5 million rays per second on the
|
||||
author’s machine.</li>
|
||||
<li>Pause and resume: Can’t run <code>./hou</code> overnight? No problem! You can kill and
|
||||
resume a rendering session whenever you want. The renderer automatically saves
|
||||
the progress every 16 samples and resumes where it’s left off when restarted.
|
||||
Also, each scene/parameter combination gets a different saved session so you
|
||||
don’t have to worry about conflicts.</li>
|
||||
</ul>
|
||||
<h3 id="abuse-of-the-rules">Abuse of the rules</h3>
|
||||
<ul>
|
||||
<li><a href="hou.c">hou.c</a> uses compression to get around the size
|
||||
limit. The compression fully complies with the rules and the guidelines
|
||||
(at least the portion that shows up in <code>grep</code> “size limit”).
|
||||
Please see the <a href="self-imposed-restrictions">Self-imposed
|
||||
<li><a href="hou.c">hou.c</a> uses compression to get around the size limit. The compression
|
||||
fully complies with the rules and the guidelines (at least the portion that
|
||||
shows up in <code>grep</code> “size limit”). Please see the <a href="self-imposed-restrictions">Self-imposed
|
||||
restrictions</a> section below for more details.</li>
|
||||
<li><code>hou</code> does not terminate (as suggested by the second line
|
||||
of rule 6).</li>
|
||||
<li><code>hou</code> does not terminate (as suggested by the second line of rule 6).</li>
|
||||
</ul>
|
||||
<h3 id="self-imposed-restrictions">Self-imposed restrictions</h3>
|
||||
<ul>
|
||||
<li>The building process does not involve any OS tool beyond
|
||||
<code>cc(1)</code> and <code>make(1)</code>. No <code>gzip(1)</code>
|
||||
compression! <code>a.c.gz</code> doesn’t fit in 2053 bytes, anyway.</li>
|
||||
<li>Neither <a href="hou.c">hou.c</a> nor <a href="a.c">a.c</a> (the
|
||||
<em>real</em> decompressed source) uses <code>#define</code> (or
|
||||
<code>cc -D</code>) at all.</li>
|
||||
<li>The building process does not involve any OS tool beyond <code>cc(1)</code> and
|
||||
<code>make(1)</code>. No <code>gzip(1)</code> compression! <code>a.c.gz</code> doesn’t fit in 2053 bytes, anyway.</li>
|
||||
<li>Neither <a href="hou.c">hou.c</a> nor <a href="a.c">a.c</a> (the <em>real</em> decompressed source) uses
|
||||
<code>#define</code> (or <code>cc -D</code>) at all.</li>
|
||||
<li>The source code is not required at runtime.</li>
|
||||
<li><a href="a.c">a.c</a> does not drop optional features to reduce
|
||||
size. There are pure optimization code that can be dropped without
|
||||
affecting the converged output (only affecting the ray tracing speed /
|
||||
convergence rate). All files are properly <code>fopen()</code>ed with
|
||||
<code>"rb"</code> / <code>"wb"</code> for Windows compatibility. The PPM
|
||||
header has a comment line for non-standard-compliant viewers
|
||||
(specifically, my old HDRShop 1.0). And there is a nice text message
|
||||
saying “please wait…”. Despite the messy look, <a href="a.c">a.c</a> and
|
||||
<a href="hou.c">hou.c</a> compile warning-free (<a
|
||||
href="hou.c">hou.c</a> even wastes 18 bytes on
|
||||
<code>#include<stdio.h></code> just for <code>putchar(3)</code>).
|
||||
<a href="a.c">a.c</a> compiles mostly clean in the C99/ANSI modes of
|
||||
clang and gcc (with <code>-Wall --pedantic</code>). The only warning
|
||||
generated is a pedantic one:
|
||||
<code>"string constant too long"</code>.</li>
|
||||
<li><a href="a.c">a.c</a> does not drop optional features to reduce size. There are pure
|
||||
optimization code that can be dropped without affecting the converged output
|
||||
(only affecting the ray tracing speed / convergence rate). All files are
|
||||
properly <code>fopen()</code>ed with <code>"rb"</code> / <code>"wb"</code> for Windows compatibility. The PPM
|
||||
header has a comment line for non-standard-compliant viewers (specifically, my
|
||||
old HDRShop 1.0). And there is a nice text message saying “please wait…”.
|
||||
Despite the messy look, <a href="a.c">a.c</a> and <a href="hou.c">hou.c</a> compile warning-free
|
||||
(<a href="hou.c">hou.c</a> even wastes 18 bytes on <code>#include<stdio.h></code> just for <code>putchar(3)</code>).
|
||||
<a href="a.c">a.c</a> compiles mostly clean in the C99/ANSI modes of clang and gcc (with <code>-Wall --pedantic</code>). The only warning generated is a pedantic one: <code>"string constant too long"</code>.</li>
|
||||
</ul>
|
||||
<h3 id="comments-and-why-obfuscated">Comments and why obfuscated</h3>
|
||||
<ul>
|
||||
<li>Both the compression and the rendering use mathematically involved
|
||||
algorithms. Understanding the C doesn’t help much if one isn’t familiar
|
||||
with the math.</li>
|
||||
<li>Modern renderers provide shader access to just about any internal
|
||||
state. This one follows suit and reuses the same shader-accessible array
|
||||
for all important internal states.</li>
|
||||
<li>Infinity and NaN (not-a-number) are used during normal course of
|
||||
execution.</li>
|
||||
<li>Previous image-generating entries may take care to hide the “IOCCC”
|
||||
string in the code, but they leave the text clear in the
|
||||
<em>result</em>. This entry takes it further and obfuscates the output
|
||||
image as well. Can you find the text in the image? Hint: look up.</li>
|
||||
<li><a href="a.c">a.c</a> leaves all shaders in plain text, but the
|
||||
plain text shader code can’t be taken for its face value; the arithmetic
|
||||
rules subtly diverge from our common sense.</li>
|
||||
<li><a href="a.c">a.c</a> is less portable than <a
|
||||
href="hou.c">hou.c</a> itself. <a href="hou.c">hou.c</a> only depends on
|
||||
ASCII and should run just fine on 16-bit, small memory, or
|
||||
floating-point-incapable machines. <a href="a.c">a.c</a>, while still
|
||||
reasonably portable, is quite memory consuming, requires
|
||||
IEEE754-compliant <code>double</code>, and assumes <code>int</code> to
|
||||
be 32-bits.</li>
|
||||
<li>Though technically endian-dependent, <a href="a.c">a.c</a> remains
|
||||
portable providing that one doesn’t copy saved sessions across different
|
||||
endianness.</li>
|
||||
<li>Both the compression and the rendering use mathematically involved algorithms.
|
||||
Understanding the C doesn’t help much if one isn’t familiar with the math.</li>
|
||||
<li>Modern renderers provide shader access to just about any internal state. This
|
||||
one follows suit and reuses the same shader-accessible array for all important
|
||||
internal states.</li>
|
||||
<li>Infinity and NaN (not-a-number) are used during normal course of execution.</li>
|
||||
<li>Previous image-generating entries may take care to hide the “IOCCC” string in
|
||||
the code, but they leave the text clear in the <em>result</em>. This entry takes it
|
||||
further and obfuscates the output image as well. Can you find the text in the
|
||||
image? Hint: look up.</li>
|
||||
<li><a href="a.c">a.c</a> leaves all shaders in plain text, but the plain text shader code can’t
|
||||
be taken for its face value; the arithmetic rules subtly diverge from our common
|
||||
sense.</li>
|
||||
<li><a href="a.c">a.c</a> is less portable than <a href="hou.c">hou.c</a> itself. <a href="hou.c">hou.c</a> only depends
|
||||
on ASCII and should run just fine on 16-bit, small memory, or
|
||||
floating-point-incapable machines. <a href="a.c">a.c</a>, while still reasonably portable, is
|
||||
quite memory consuming, requires IEEE754-compliant <code>double</code>, and assumes <code>int</code> to be
|
||||
32-bits.</li>
|
||||
<li>Though technically endian-dependent, <a href="a.c">a.c</a> remains portable providing that one
|
||||
doesn’t copy saved sessions across different endianness.</li>
|
||||
</ul>
|
||||
<h3 id="spoiler">Spoiler</h3>
|
||||
<pre><code> 3225 3225 3225 9 9 3225 3225
|
||||
@@ -311,132 +283,90 @@ endianness.</li>
|
||||
4225 1226 1 1 1 1 1222 1226
|
||||
1 1 1 1 1 1 1 1 1
|
||||
4226 1 4226 8 4222 4226 1 1</code></pre>
|
||||
<p>The program consists of a recursive-descent interpreter, a
|
||||
<code>3DDDA</code> (3D Discrete Differential Analysis) ray tracer, a
|
||||
<code>PSSMLT</code> (Primary Sample Space Metropolis Light Transport)
|
||||
light path sampler, all squeezed into the size limit using a
|
||||
<code>PPM</code> compressor (Prediction by Partial Matching, and yes,
|
||||
the output format is chosen for the pun..).</p>
|
||||
<p><code>PSSMLT</code> uses the Metropolis-Hasting algorithm to sample a
|
||||
32D unit hypercube. Each point in the hypercube is interpreted as a
|
||||
sequence of random numbers, and is sent to a path tracer to generate a
|
||||
light path. The point’s Metropolis-Hasting energy is then defined as the
|
||||
corresponding path’s contribution value to the final image. Since each
|
||||
path is sampled with a probability proportional to its energy, the
|
||||
sample distribution directly corresponds to the final image, which can
|
||||
then be produced as a simple per-pixel histogram of all generated paths.
|
||||
The robustness comes from a state mutation strategy that actively tries
|
||||
to explore the neighborhood of high energy peaks (e.g. paths that happen
|
||||
to hit the light source in <a
|
||||
href="otherroom.scene">otherroom.scene</a>). In addition, a rudimentary
|
||||
form of lens path stratification is added to balance the attention each
|
||||
pixel receives. The Metropolis-Hasting process completely avoids the
|
||||
tell-tale pixel sampling loop required in most other image generation
|
||||
methods.</p>
|
||||
<p>The <code>3DDDA</code> tracer is chosen for scalability: its
|
||||
performance doesn’t get much worse as scene complexity increases.
|
||||
Another benefit is that with the <code>DDA</code> code in place one can
|
||||
naturally use hierarchical grids as an acceleration structure. The
|
||||
downside, of course, is that the setup involves quite a few divisions,
|
||||
which naturally turns into divisions-by-zero. Fortunately, the IEEE754
|
||||
standard has a nice set of rules just for this purpose and the
|
||||
arithmetics are organized in a specific way to take advantage of this.
|
||||
The shader interpreter component is relatively straightforward, just an
|
||||
expression evaluator stripped to the bare minimum – it doesn’t even
|
||||
support numerical constants natively. A final little bit is a
|
||||
just-good-enough PRNG (Pseudo Random Number Generator) to replace the
|
||||
low precision Windows <code>rand()</code> and the non-C99 Unix
|
||||
<code>drand48(3)</code>. An overnight session would run through its
|
||||
short period many times, but that doesn’t necessarily map to the same
|
||||
set of paths in <code>PSSMLT</code>. After all, Metropolis-Hasting used
|
||||
an even worse PRNG in their 1953 paper.</p>
|
||||
<p>The <code>PPM</code> compressor uses statically weighted fixed order
|
||||
contexts with an arithmetic encoder tweaked for <a
|
||||
href="../iocccsize.c">iocccsize.c</a>. The encoder emits octet-space
|
||||
pairs where each octet encodes ~6.5 bits of information and each space
|
||||
encodes 2 bits (thanks to the generous definition of “space” in <a
|
||||
href="../iocccsize.c">iocccsize.c</a>). The compressor actively shuffles
|
||||
the variable names around until the compressed string happens to contain
|
||||
enough <code>{};</code>s to pass the final <a
|
||||
href="../iocccsize.c">iocccsize.c</a> test. There are a few other
|
||||
tweaks:</p>
|
||||
<p>The program consists of a recursive-descent interpreter, a <code>3DDDA</code> (3D Discrete
|
||||
Differential Analysis) ray tracer, a <code>PSSMLT</code> (Primary Sample Space Metropolis
|
||||
Light Transport) light path sampler, all squeezed into the size limit using a
|
||||
<code>PPM</code> compressor (Prediction by Partial Matching, and yes, the output format is
|
||||
chosen for the pun..).</p>
|
||||
<p><code>PSSMLT</code> uses the Metropolis-Hasting algorithm to sample a 32D unit hypercube.
|
||||
Each point in the hypercube is interpreted as a sequence of random numbers, and
|
||||
is sent to a path tracer to generate a light path. The point’s
|
||||
Metropolis-Hasting energy is then defined as the corresponding path’s
|
||||
contribution value to the final image. Since each path is sampled with a
|
||||
probability proportional to its energy, the sample distribution directly
|
||||
corresponds to the final image, which can then be produced as a simple per-pixel
|
||||
histogram of all generated paths. The robustness comes from a state mutation
|
||||
strategy that actively tries to explore the neighborhood of high energy peaks
|
||||
(e.g. paths that happen to hit the light source in
|
||||
<a href="otherroom.scene">otherroom.scene</a>). In addition, a rudimentary form of lens
|
||||
path stratification is added to balance the attention each pixel receives. The
|
||||
Metropolis-Hasting process completely avoids the tell-tale pixel sampling loop
|
||||
required in most other image generation methods.</p>
|
||||
<p>The <code>3DDDA</code> tracer is chosen for scalability: its performance doesn’t get much
|
||||
worse as scene complexity increases. Another benefit is that with the <code>DDA</code> code
|
||||
in place one can naturally use hierarchical grids as an acceleration structure.
|
||||
The downside, of course, is that the setup involves quite a few divisions, which
|
||||
naturally turns into divisions-by-zero. Fortunately, the IEEE754 standard has a
|
||||
nice set of rules just for this purpose and the arithmetics are organized in a
|
||||
specific way to take advantage of this. The shader interpreter component is
|
||||
relatively straightforward, just an expression evaluator stripped to the bare
|
||||
minimum – it doesn’t even support numerical constants natively. A final little
|
||||
bit is a just-good-enough PRNG (Pseudo Random Number Generator) to replace the
|
||||
low precision Windows <code>rand()</code> and the non-C99 Unix <code>drand48(3)</code>. An overnight
|
||||
session would run through its short period many times, but that doesn’t
|
||||
necessarily map to the same set of paths in <code>PSSMLT</code>. After all,
|
||||
Metropolis-Hasting used an even worse PRNG in their 1953 paper.</p>
|
||||
<p>The <code>PPM</code> compressor uses statically weighted fixed order contexts with an
|
||||
arithmetic encoder tweaked for <a href="../iocccsize.c">iocccsize.c</a>. The encoder emits octet-space pairs
|
||||
where each octet encodes ~6.5 bits of information and each space encodes 2 bits
|
||||
(thanks to the generous definition of “space” in <a href="../iocccsize.c">iocccsize.c</a>). The compressor
|
||||
actively shuffles the variable names around until the compressed string happens
|
||||
to contain enough <code>{};</code>s to pass the final <a href="../iocccsize.c">iocccsize.c</a> test.
|
||||
There are a few other tweaks:</p>
|
||||
<ul>
|
||||
<li><p>The <code>PPM</code> model uses mostly whitespace characters for
|
||||
weights.</p></li>
|
||||
<li><p>The encoder never emits <code>'"'</code> and
|
||||
<code>'\\'</code>.</p></li>
|
||||
<li><p>The decoder uses an O(n^2) algorithm to avoid the gigabytes-sized
|
||||
hash table frequently found in other <code>PPM</code>
|
||||
implementations.</p></li>
|
||||
<li><p>The <code>PPM</code> model uses mostly whitespace characters for weights.</p></li>
|
||||
<li><p>The encoder never emits <code>'"'</code> and <code>'\\'</code>.</p></li>
|
||||
<li><p>The decoder uses an O(n^2) algorithm to avoid the gigabytes-sized hash table
|
||||
frequently found in other <code>PPM</code> implementations.</p></li>
|
||||
</ul>
|
||||
<h2 id="copyright-and-cc-by-sa-4.0-license">Copyright and CC BY-SA 4.0
|
||||
License:</h2>
|
||||
<p>This file is Copyright (c) 2023 by Landon Curt Noll. All Rights
|
||||
Reserved. You are free to share and adapt this file under the terms of
|
||||
this license:</p>
|
||||
<h2 id="copyright-and-cc-by-sa-4.0-license">Copyright and CC BY-SA 4.0 License:</h2>
|
||||
<p>This file is Copyright (c) 2023 by Landon Curt Noll. All Rights Reserved.
|
||||
You are free to share and adapt this file under the terms of this license:</p>
|
||||
<pre><code>Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)</code></pre>
|
||||
<p>For more information, see:
|
||||
https://creativecommons.org/licenses/by-sa/4.0/</p>
|
||||
<p>For more information, see: https://creativecommons.org/licenses/by-sa/4.0/</p>
|
||||
|
||||
<!-- END: this line ends content for HTML phase 21 by: bin/pandoc-wrapper.sh via bin/md2html.sh -->
|
||||
<!-- START: this line starts content for HTML phase 22 by: bin/output-index-inventory.sh via bin/md2html.sh -->
|
||||
|
||||
<!-- START: this line starts content generated by: bin/output-index-inventory.sh -->
|
||||
|
||||
<h1 id="inventory-for-2013hou"><a name="inventory"></a>Inventory for
|
||||
2013/hou</h1>
|
||||
<h1 id="inventory-for-2013hou"><a name="inventory"></a>Inventory for 2013/hou</h1>
|
||||
<p><a href="#top">Jump to top</a></p>
|
||||
<h2 id="primary-files">Primary files</h2>
|
||||
<ul>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2013/hou/hou.c">hou.c</a>
|
||||
- entry source</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2013/hou/Makefile">Makefile</a>
|
||||
- entry Makefile</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2013/hou/hou.orig.c">hou.orig.c</a>
|
||||
- original source</li>
|
||||
<li><a href="doc/example.html">doc/example.html</a> - detailed
|
||||
information about entry</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2013/hou/old_default.scene">old_default.scene</a>
|
||||
- sample input</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2013/hou/otherroom.scene">otherroom.scene</a>
|
||||
- sample input</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2013/hou/try.sh">try.sh</a>
|
||||
- how to run</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2013/hou/hou.c">hou.c</a> - entry source</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2013/hou/Makefile">Makefile</a> - entry Makefile</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2013/hou/hou.orig.c">hou.orig.c</a> - original source</li>
|
||||
<li><a href="doc/example.html">doc/example.html</a> - detailed information about entry</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2013/hou/old_default.scene">old_default.scene</a> - sample input</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2013/hou/otherroom.scene">otherroom.scene</a> - sample input</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2013/hou/try.sh">try.sh</a> - how to run</li>
|
||||
<li><a href="luna.jpg">luna.jpg</a> - sample image data</li>
|
||||
<li><a href="old_default.jpg">old_default.jpg</a> - sample image
|
||||
data</li>
|
||||
<li><a href="old_default.jpg">old_default.jpg</a> - sample image data</li>
|
||||
<li><a href="otherroom.jpg">otherroom.jpg</a> - sample image data</li>
|
||||
<li><a href="2013_hou.tar.bz2">2013_hou.tar.bz2</a> - download entry
|
||||
source</li>
|
||||
<li><a href="2013_hou.tar.bz2">2013_hou.tar.bz2</a> - download entry source</li>
|
||||
</ul>
|
||||
<h2 id="secondary-files">Secondary files</h2>
|
||||
<ul>
|
||||
<li><a href="index.html">index.html</a> - entry home page</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2013/hou/.entry.json">.entry.json</a>
|
||||
- description of entry in JSON</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2013/hou/.gitignore">.gitignore</a>
|
||||
- list of files that should not be committed under git</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2013/hou/.entry.json">.entry.json</a> - description of entry in JSON</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2013/hou/.gitignore">.gitignore</a> - list of files that should not be committed under git</li>
|
||||
<li><a href=".path">.path</a> - directory path from top directory</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2013/hou/README.md">README.md</a>
|
||||
- markdown source for index.html</li>
|
||||
<li><a href="doc/camera.png">doc/camera.png</a> - documentation support
|
||||
image</li>
|
||||
<li><a href="doc/cosine.png">doc/cosine.png</a> - documentation support
|
||||
image</li>
|
||||
<li><a href="doc/draft.png">doc/draft.png</a> - documentation support
|
||||
image</li>
|
||||
<li><a
|
||||
href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2013/hou/doc/example.md">doc/example.md</a>
|
||||
- markdown source for doc/example.html</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2013/hou/README.md">README.md</a> - markdown source for index.html</li>
|
||||
<li><a href="doc/camera.png">doc/camera.png</a> - documentation support image</li>
|
||||
<li><a href="doc/cosine.png">doc/cosine.png</a> - documentation support image</li>
|
||||
<li><a href="doc/draft.png">doc/draft.png</a> - documentation support image</li>
|
||||
<li><a href="https://github.com/ioccc-src/temp-test-ioccc/blob/master/2013/hou/doc/example.md">doc/example.md</a> - markdown source for doc/example.html</li>
|
||||
</ul>
|
||||
|
||||
<!-- END: next line ends content generated by: bin/output-index-inventory.sh -->
|
||||
|
||||
Reference in new issue
Block a user