mirror/ioccc
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Format/typo check 2013/hou

Browse Source
This commit is contained in:
Cody Boone Ferguson committed 2023-12-03 09:10:37 -08:00
1 parent a478f8835f
commit a441c47ec0
3 files changed
+454 -308
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

2013/hou/README.md
+36 -39
View File
@@ -51,13 +51,6 @@ of the invocations above:
This program does not terminate by itself: you must kill `hou` (but not Qiming
Hou :-) ) in order to end the program.
This is supposed to happen. As is written in the
[The Jargon File](http://catb.org/jargon/html/F/feature.html):
```
That's not a bug, that's a feature.
```
## Judges' remarks:
@@ -69,7 +62,7 @@ program.
This program will loop infinitely while progressively refining a
[raytraced](https://en.wikipedia.org/wiki/Ray_tracing_(graphics)) image.
NOTE: the author refers to `a.c`, placed in a gzipped file `a.c.gz`. We do not
NOTE: the author refers to [a.c](a.c), placed in a gzipped file `a.c.gz`. We do not
include it but it can be generated like:
```sh
@@ -101,6 +94,7 @@ after you're satisfied with the image quality.
To save time and energy for the judges, rendered images for all provided scenes
are provided as attached files.
### Features
* Fully programmable: Almost every stage of the renderer is programmable with
@@ -134,6 +128,7 @@ 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.
### Abuse of the rules
* [hou.c](hou.c) uses compression to get around the size limit. The compression
@@ -142,25 +137,27 @@ shows up in `grep` "size limit"). Please see the [Self-imposed
restrictions](self-imposed-restrictions) section below for more details.
* `hou` does not terminate (as suggested by the second line of rule 6).
### Self-imposed restrictions
* The building process does not involve any OS tool beyond cc and make. No gzip
compression! `a.c.gz` doesn't fit in 2053 bytes, anyway.
* Neither [hou.c](hou.c) nor `a.c` (the *real* decompressed source) uses
* The building process does not involve any OS tool beyond `cc(1)` and
`make(1)`. No `gzip(1)` compression! `a.c.gz` doesn't fit in 2053 bytes, anyway.
* Neither [hou.c](hou.c) nor [a.c](a.c) (the *real* decompressed source) uses
`#define` (or `cc -D`) at all.
* The source code is not required at runtime.
* `a.c` does not drop optional features to reduce size. There are pure
* [a.c](a.c) 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 `fopen()`ed with `"rb"` / `"wb"` 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.c` and [hou.c](hou.c) compile warning-free
([hou.c](hou.c) even wastes 18 bytes on `#include<stdio.h>` just for putchar).
`a.c` compiles mostly clean in the C99/ANSI modes of clang and gcc (with `-Wall
Despite the messy look, [a.c](a.c) and [hou.c](hou.c) compile warning-free
([hou.c](hou.c) even wastes 18 bytes on `#include<stdio.h>` just for `putchar(3)`).
[a.c](a.c) compiles mostly clean in the C99/ANSI modes of clang and gcc (with `-Wall
--pedantic`). The only warning generated is a pedantic one: `"string constant
too long"`.
### Comments and why obfuscated
* Both the compression and the rendering use mathematically involved algorithms.
@@ -173,35 +170,35 @@ internal states.
the code, but they leave the text clear in the *result*. This entry takes it
further and obfuscates the output image as well. Can you find the text in the
image? Hint: look up.
* `a.c` leaves all shaders in plain text, but the plain text shader code can't
* [a.c](a.c) 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.
* `a.c` is less portable than [hou.c](hou.c) itself. [hou.c](hou.c) only depends
* [a.c](a.c) is less portable than [hou.c](hou.c) itself. [hou.c](hou.c) only depends
on ASCII and should run just fine on 16-bit, small memory, or
floating-point-incapable machines. `a.c`, while still reasonably portable, is
quite memory consuming, requires IEEE754-compliant double, and assumes int to be
32-bit.
* Though technically endian-dependent, `a.c` remains portable providing that one
floating-point-incapable machines. [a.c](a.c), while still reasonably portable, is
quite memory consuming, requires IEEE754-compliant `double`, and assumes `int` to be
32-bits.
* Though technically endian-dependent, [a.c](a.c) remains portable providing that one
doesn't copy saved sessions across different endianness.
### Spoiler
```
3225 3225 3225 9 9 3225 3225
1 1 1 1 1 1 1 1 1 1\
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
3225 3225 3225 9 9 3225 3225
1 1 1 1 1 1 1 1 1 1
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
```
The program consists of a recursive-descent interpreter, a 3DDDA (3D Discrete
Differential Analysis) ray tracer, a PSSMLT (Primary Sample Space Metropolis
The program consists of a recursive-descent interpreter, a `3DDDA` (3D Discrete
Differential Analysis) ray tracer, a `PSSMLT` (Primary Sample Space Metropolis
Light Transport) light path sampler, all squeezed into the size limit using a
PPM compressor (Prediction by Partial Matching, and yes, the output format is
`PPM` compressor (Prediction by Partial Matching, and yes, the output format is
chosen for the pun..).
PSSMLT uses the Metropolis-Hasting algorithm to sample a 32D unit hypercube.
`PSSMLT` 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
@@ -216,8 +213,8 @@ 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.
The 3DDDA tracer is chosen for scalability: its performance doesn't get much
worse as scene complexity increases. Another benefit is that with the DDA code
The `3DDDA` tracer is chosen for scalability: its performance doesn't get much
worse as scene complexity increases. Another benefit is that with the `DDA` 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
@@ -226,25 +223,25 @@ 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 rand() and the non-C99 Unix drand48(). An overnight
low precision Windows `rand()` and the non-C99 Unix `drand48(3)`. An overnight
session would run through its short period many times, but that doesn't
necessarily map to the same set of paths in PSSMLT. After all,
necessarily map to the same set of paths in `PSSMLT`. After all,
Metropolis-Hasting used an even worse PRNG in their 1953 paper.
The PPM compressor uses statically weighted fixed order contexts with an
The `PPM` compressor uses statically weighted fixed order contexts with an
arithmetic encoder tweaked for [iocccsize.c](../iocccsize.c). 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 [iocccsize.c](../iocccsize.c)). The compressor
actively shuffles the variable names around until the compressed string happens
to contain enough `{}; ` to pass the final [iocccsize.c](../iocccsize.c) test.
to contain enough `{}; `s to pass the final [iocccsize.c](../iocccsize.c) test.
There are a few other tweaks:
* The PPM model uses mostly whitespace characters for weights.
* The `PPM` model uses mostly whitespace characters for weights.
* The encoder never emits `'"'` and `'\\'`.
* The decoder uses an O(n^2) algorithm to avoid the gigabytes-sized hash table
frequently found in other PPM implementations.
frequently found in other `PPM` implementations.
## Copyright and CC BY-SA 4.0 License:
2013/hou/doc/example.md
+414 -265
View File
@@ -1,352 +1,501 @@
# Scene format documentation
This file is encoded in UTF-8 as the BOF marker indicates.
The file must be encoded in UTF-8 as the BOF marker indicates.
You can directly feed it to the renderer. If you're wondering about what the following code block does, that's why:)
@|?|?z#
@|||?z&
>?Sedvf
??Tdeu#
>>Tdeui
??Tdmmf
??[[euf
?}?Oq}e
?}?Oqqf
v}?|q}e
v}?|qqf
?Sj|?{f
?Tjk?{e
FF?Oqq$
RR?Oqq$
^^?Oqq$
jj?Oqq$
vv?|qq$
IOBMqqe
U]BMqqe
aiBMqqe
muBMqqe
EEEJpp%
QQEJpp%
]]EJpp%
iiEJpp%
uuEJpp%
ZnY|{|e
[mZ|\{\{#
[mZ|||f
kkdr\{\{\%
lkdr\{\{>
```
@|?|?z#
@|||?z&
>?Sedvf
??Tdeu#
>>Tdeui
??Tdmmf
??[[euf
?}?Oq}e
?}?Oqqf
v}?|q}e
v}?|qqf
?Sj|?{f
?Tjk?{e
FF?Oqq$
RR?Oqq$
^^?Oqq$
jj?Oqq$
vv?|qq$
IOBMqqe
U]BMqqe
aiBMqqe
muBMqqe
EEEJpp%
QQEJpp%
]]EJpp%
iiEJpp%
uuEJpp%
ZnY|{|e
[mZ|\{\{#
[mZ|||f
kkdr\{\{\%
lkdr\{\{>
```
## Basic structure
A scene file begins with arbitrary binary data, followed by several shader functions.
A scene file begins with arbitrary binary data, followed by several shader
functions.
Shader functions are declared using a one-character name followed by a ']' character. There are some special function names, which will be explained below.
Shader functions are declared using a one-character name followed by a `]`
character. There are some special function names, which will be explained below.
The language used to write shader functions is very simple. Basically, you write
a sequence of assignment statements like this:
```
A=A+D
B=B+E
```
Namely, you write a one-character variable name, an equal sign (`=`), followed
by an expression (made of operators and one-character variable names, of
course).
The language used to write shader functions is very simple. Basically, you write a sequence of assignment statements like this:
A=A+D
B=B+E
Namely, you write a one-character variable name, an equal sign '=', followed by an expression (made of operators and one-character variable names, of course).
## Expressions
The shader language supports seven operators, listed highest priority first:
*/+-<#:
`*/+-<` mean what they mean in C, but the priority part is a bit different. Basically, `*` has higher priority than `/`, so `A/4*4` actually computes `A/(4*4)`. And you can't write `(A/4)*4` -- brackets are not supported. As an advice, keep your expressions simple :) If you really needs to write something like C=(A/4)*4, write instead:
B=A/4+
C=B*4
```
*/+-<#:
```
The # operator acts somewhat like the C ?:. It returns one of its two operands based on, what else, the value of variable #. When # is true, # returns its second operand.
`*/+-<` each mean what they mean in C, but the priority part is a bit different.
Basically, `*` has higher priority than `/`, so `A/4*4` actually computes
`A/(4*4)`. And you can't write `(A/4)*4` -- brackets are not supported. As an
advice, keep your expressions simple :) If you really needs to write something
like `C=(A/4)*4`, write instead:
The : operator calls built-in functions. The first operand is the function id and the second is the parameter. Here is a list of functions:
0:x = the x-th byte of the scene file
1:x = sin(x*PI)
2:x = atan2(x,#)/PI
3:x = sqrt(max(x,0))
4:x = floor(x)
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)
```
B=A/4+
C=B*4
```
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 3=1+1, you can use single digit numbers as, well, single digit numbers. If you need something like 1920 or 0.73, you need to compute it yourself. And yes, all variables store floating point values.
The `#` operator acts somewhat like the C `?:`. It returns one of its two
operands based on, what else, the value of variable `#`. When `#` is true, `#`
returns its second operand.
If a character appears as the first character of any argv, it goes to zero. This includes the scene filename. If you name your scene '1.scene', well, good luck with 1=0!
The `:` operator calls built-in functions. The first operand is the function id and the second is the parameter. Here is a list of functions:
You can terminate a statement using any character that isn't an operator, be it \n or ;. But you must put in one and only one character. Put in two (e.g. the Windows \r\n), and it terminates your function. Also, the first statement must begin immediately after ']'.
```
0:x = the x-th byte of the scene file
1:x = sin(x*PI)
2:x = atan2(x,#)/PI
3:x = sqrt(max(x,0))
4:x = floor(x)
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)
```
When a function terminates, the interpreter calls the next function specified by variable R. If you want to call function 'n', just write somewhere:
R=n
providing you have left n at its initial value. If you want to actually return to the renderer, put in R=0.
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 `3=1+1`,
you can use single digit numbers as, well, single digit numbers. If you need
something like `1920` or `0.73`, you need to compute it yourself. And yes, all
variables store floating point values.
If a character appears as the first character of any `argv`, it goes to zero.
This includes the scene filename. If you name your scene `1.scene`, well, good
luck with `1=0`!
You can terminate a statement using any character that isn't an operator, be it
`\n` or `;`. But you must put in one and only one character. Put in two (e.g.
the Windows `\r\n`), and it terminates your function. Also, the first statement
must begin immediately after `]`.
When a function terminates, the interpreter calls the next function specified by
variable `R`. If you want to call function `n`, just write somewhere:
```
R=n
```
providing you have left `n` at its initial value. If you want to actually return
to the renderer, put in `R=0`.
As you may have noticed, you can put in all kinds of stuff between functions,
like this comment.
As you may have noticed, you can put in all kinds of stuff between functions, like this comment.
## How the ____ do I render an image with shaders?
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.
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.
-------------------------------------------
Continue to the comments before function A
-------------------------------------------
//As an (optional) assignment, figure out what function `n` does. And why there is a plus sign at every EOL except the last.
n]#=1+
x=X+1/2+
d=0:U;d=d-n;U=U+1;A=d<x;#=#*A+
d=0:U;d=d-n;U=U+1;A=x<d+1;#=#*A+
x=Y+1/2+
d=0:U;d=d-n;U=U+1;A=d<x;#=#*A+
d=0:U;d=d-n;U=U+1;A=x<d+1;#=#*A+
x=Z+1/2+
d=0:U;d=d-n;U=U+1;A=d<x;#=#*A+
d=0:U;d=d-n;U=U+1;A=x<d+1;#=#*A+
d=0:U;d=d-n;U=U+1+
U=U+2+
C=C#d+3*9+
#=d+
R=0#n
```
//As an (optional) assignment, figure out what function 'n' does. And why there is a plus sign at every EOL except the last.
n]#=1+
x=X+1/2+
d=0:U;d=d-n;U=U+1;A=d<x;#=#*A+
d=0:U;d=d-n;U=U+1;A=x<d+1;#=#*A+
x=Y+1/2+
d=0:U;d=d-n;U=U+1;A=d<x;#=#*A+
d=0:U;d=d-n;U=U+1;A=x<d+1;#=#*A+
x=Z+1/2+
d=0:U;d=d-n;U=U+1;A=d<x;#=#*A+
d=0:U;d=d-n;U=U+1;A=x<d+1;#=#*A+
d=0:U;d=d-n;U=U+1+
U=U+2+
C=C#d+3*9+
#=d+
R=0#n
```
-------------------------------------------
The function "A" initializes global settings:
G -- Image width, in pixels
H -- Image height, in pixels
I -- Perturbation probability
J -- Camera ray stratification probability
If you have used a MLT renderer before, you probably know what I and J 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 I if your scene is primarily illuminated by some indirect source.
The function `A` initializes global settings:
"A" 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 round-ish characters in old_default.scene and the carpet on the floor in this file are examples where a cell is defined to another volume. Materials will be explained later.
```
G -- Image width, in pixels
H -- Image height, in pixels
I -- Perturbation probability
J -- Camera ray stratification probability
```
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 x,y,z, and you're supposed to return the cell content in variable C. To fill it with material i, return 64+i in C. To fill it with volume i, well, return i. To leave it empty, return C=0.
If you have used a MLT renderer before, you probably know what `I` and `J` 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 `I` if your scene is primarily illuminated by some
indirect source.
Before starting to build a scene, it's better to have a draft sketch handy first. Something like ![ Draft sketch ](draft.png). Sometimes it's hard to imagine where something should go without the sketch. And you don't have to stick to your sketch :)
`A` 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
[old_default.scene](../old_default.scene) and the carpet on the floor in this
file are examples where a cell is defined to another volume. Materials will be
explained later.
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 `x`,`y`,`z`, and you're supposed to return the
cell content in variable `C`. To fill it with material `i`, return `64+i` in
`C`. To fill it with volume `i`, well, return `i`. To leave it empty, return
`C=0`.
Before starting to build a scene, it's better to have a draft sketch handy
first. Something like ![ Draft sketch ](draft.png). Sometimes it's hard to
imagine where something should go without the sketch. And you don't have to
stick to your sketch :)
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.
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.
-------------------------------------------
Continue to the comments before function a
-------------------------------------------
//As a bonus, find out what the first line does
A]#=#-#;"=7:0-p+^;#="+
R=n+
G=p*:+
#=0<B+
G=G*2#G+
H=G*3/4+
I=4/5+
J=1/2+
C=p+1+
U=w+w+w
```
//As a bonus, find out what the first line does
A]#=#-#;"=7:0-p+^;#="+
R=n+
G=p*:+
#=0<B+
G=G*2#G+
H=G*3/4+
I=4/5+
J=1/2+
C=p+1+
U=w+w+w
```
-------------------------------------------
The function 'a' is the camera shader, which, well, generates the camera ray. It's supposed to return the ray in variables UVWXYZ and ABCDEF (that may sound like a lot of variables, but it really isn't that much).
The function `a` is the camera shader, which, well, generates the camera ray.
It's supposed to return the ray in variables `UVWXYZ` and `ABCDEF` (that may
sound like a lot of variables, but it really isn't that much).
Here comes some subtlety of PSSMLT (Primary Sample Space Metropolis Light Transport, or Kelemen-style MLT). Basically, a PSSMLT 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.
Here comes some subtlety of `PSSMLT` (Primary Sample Space Metropolis Light
Transport, or Kelemen-style MLT). Basically, a `PSSMLT` 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.
Remember the function 5? Here it comes. The first two "random" numbers have special meaning and must specify a point on the image plane [0,1)x[0,1). 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 ![ Camera convention ](camera.png). The camera point goes to (U,V,W), and the ray direction vector (image plane point - camera point) is (X,Y,Z). For the coordinate space, volume 0 is scaled up 64x here to (0,0,0)-(4096,4096,4096).
Remember the function `5`? Here it comes. The first two "random" numbers have
special meaning and must specify a point on the image plane `[0,1)x[0,1)`.
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
![ Camera convention ](camera.png). The camera point goes to `(U,V,W)`, and the
ray direction vector (image plane point - camera point) is `(X,Y,Z)`. For the
coordinate space, volume 0 is scaled up 64x here to `(0,0,0)-(4096,4096,4096)`.
For a basic camera shader example, check "otherroom.scene".
For a basic camera shader example, check [otherroom.scene](../otherroom.scene).
If any ray goes out of volume 0, the renderer crashes. Make sure it doesn't happen. Wall up everything.
If any ray goes out of volume 0, the renderer crashes. Make sure it doesn't
happen. Wall up everything.
Variables ABCDEF control the color returned from the ray. They will be explained in the material shaders part. For now, just put in:
A=0;B=0;C=0
D=1;E=1;F=1
Variables `ABCDEF` control the color returned from the ray. They will be
explained in the material shaders part. For now, just put in:
```
A=0;B=0;C=0
D=1;E=1;F=1
```
-------------------------------------------
Continue to the comments before function 1
-------------------------------------------
a]R=0+
X=5:5+
Y=5:5+
X=X-1/2+
Y=Y-1/2+
x=5:5+
y=5:5+
x=x-1/2+
y=y-1/2+
x=x*8*7;y=y*8*7+
X=X*G+
Y=Y*H+
Z=H*2/3+
d=4*;+
d=d*p/Z+
X=x+X*d+
Y=y+Y*d+
Z=Z*d+
U=p*p/2-p*2+x+
V=p*p/2+p*1-y+
W=p*8+
A=0;B=0;C=0+
D=1;E=1;F=1
```
a]R=0+
X=5:5+
Y=5:5+
X=X-1/2+
Y=Y-1/2+
x=5:5+
y=5:5+
x=x-1/2+
y=y-1/2+
x=x*8*7;y=y*8*7+
X=X*G+
Y=Y*H+
Z=H*2/3+
d=4*;+
d=d*p/Z+
X=x+X*d+
Y=y+Y*d+
Z=Z*d+
U=p*p/2-p*2+x+
V=p*p/2+p*1-y+
W=p*8+
A=0;B=0;C=0+
D=1;E=1;F=1
```
--------------------------------------------------------
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 UVWXYZABCDEF, of course.
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 `UVWXYZABCDEF`, of course.
ABCDEF define colors. (A,B,C) is the RGB irradiance ultimately returned to the renderer, and (D,E,F) maintains 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 (D,E,F), multiplied by the light strength, to (A,B,C). See shader 6 for an example.
`ABCDEF` define colors. `(A,B,C)` is the RGB irradiance ultimately returned to
the renderer, and `(D,E,F)` 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 `(D,E,F)`, multiplied
by the light strength, to `(A,B,C)`. See shader 6 for an example.
If you want a colored surface, use its color to modulate (D,E,F), i.e. D=D*red;E=E*green;F=F*blue, easy as that. To get some texturing, compute the color procedurally or look up a binary table.
There's something subtle about colors. To go along with the trend, the renderer follows the practice of linear rendering with a gamma of 2. Stripping the fancy jargons, 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 *square*. 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 sqrt in a.c is for.
If you want a colored surface, use its color to modulate `(D,E,F)`, i.e.
`D=D*red;E=E*green;F=F*blue`, easy as that. To get some texturing, compute the
color procedurally or look up a binary table.
There's something subtle about colors. To go along with the trend, the renderer
follows the practice of linear rendering with a gamma of `2`. 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 *square*. 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 `sqrt(3)` in
[a.c](../a.c) is for.
Going beyond colors, to define a shiny or dull surface one needs more maths, and
optics. The jargon for this is `BRDF` (Bidirectional Reflectance Distribution
Function) importance sampling. Let's continue to function `o`.
Going beyond colors, to define a shiny or dull surface one needs more maths, and optics. The jargon for this is BRDF (Bidirectional Reflectance Distribution Function) importance sampling. Let's continue to function o.
-------------------------------------------
Continue to the comments before function o
-------------------------------------------
//This function computes the starred wallpaper
//Original color: 0.36 0.714285 0.8
1]R=o+
d=p*6+
x=U+W+
x=4:x/d+
z=4:V/d+
#=3*x-4*z+
y=4:#/5+
#=#-y*5+
y=1#0+
x=x*d+d/2-U+W+
z=z*d+d/2-V+
r=3:x*x+z*z+
#=z+
u=2:x+
d=1:u*5+
d=d*d*d+3/2+
d=d*p+
#=r<d+
#=#*y+
d=2/5#I+
D=D*d+
E=E*4/7+
d=I#2/5+
F=F*d
```
//This function computes the starred wallpaper
//Original color: 0.36 0.714285 0.8
1]R=o+
d=p*6+
x=U+W+
x=4:x/d+
z=4:V/d+
#=3*x-4*z+
y=4:#/5+
#=#-y*5+
y=1#0+
x=x*d+d/2-U+W+
z=z*d+d/2-V+
r=3:x*x+z*z+
#=z+
u=2:x+
d=1:u*5+
d=d*d*d+3/2+
d=d*p+
#=r<d+
#=#*y+
d=2/5#I+
D=D*d+
E=E*4/7+
d=I#2/5+
F=F*d
```
-------------------------------------------
Function o 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 BRDF) on that direction. For a diffuse surface, sample the upper hemisphere with a probability proportional to the cosine of the outgoing angle, see ![ Cosine sampling ](cosine.png).
Function `o` 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 `BRDF`) on that direction. For a
diffuse surface, sample the upper hemisphere with a probability proportional to
the cosine of the outgoing angle, see ![ Cosine sampling ](cosine.png).
The incoming direction is in (X,Y,Z) and the hit point is (U,V,W). The outgoing direction is returned in, where else, (X,Y,Z).
The incoming direction is in `(X,Y,Z)` and the hit point is `(U,V,W)`. The
outgoing direction is returned in, where else, `(X,Y,Z)`.
The surface normal is provided in variables S and T. Since the geometry is defined as a bunch of cube-shaped cells, there are only 6 possible normals: (±1,0,0) (0,±1,0) (0,0,±1). Here S is the sign and T is the dimension. If you get S=-1 and T=1, the normal is (0,-1,0).
The surface normal is provided in variables `S` and `T`. Since the geometry is
defined as a bunch of cube-shaped cells, there are only 6 possible normals:
`(±1,0,0) (0,±1,0) (0,0,±1)`. Here `S` is the sign and `T` is the dimension. If
you get `S=-1` and `T=1`, the normal is `(0,-1,0)`.
If you don't want to redo all the math yourself... this file provides a few simple shader functions:
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.
For something more complex like a fluffy carpet, well, you could use a volume to directly model the mesoscopic detail. Shader D in this file produces a bunch of dense, tiny spikes to simulate a fluffy appearance.
```
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.
```
For something more complex like a fluffy carpet, well, you could use a volume to
directly model the
[mesoscopic](https://en.wikipedia.org/wiki/Mesoscopic_physics) detail. Shader
`D` in this file produces a bunch of dense, tiny spikes to simulate a fluffy
appearance.
-------------------------------------------
Continue to the EOF
-------------------------------------------
//diffuse ray generation
o]R=0+
u=5:5+
v=5:5+
v=v*2+
r=3:u+
z=1:v+
y=1:1/2+v+
z=z*r+
y=y*r+
x=3:1-u+
x=0-x*S+
X=6:T+
w=x;x=z;z=y;y=w+
Y=6:T+
w=x;x=z;z=y;y=w+
Z=6:T
```
//diffuse ray generation
o]R=0+
u=5:5+
v=5:5+
v=v*2+
r=3:u+
z=1:v+
y=1:1/2+v+
z=z*r+
y=y*r+
x=3:1-u+
x=0-x*S+
X=6:T+
w=x;x=z;z=y;y=w+
Y=6:T+
w=x;x=z;z=y;y=w+
Z=6:T
//reflector
5]R=0+
x=1;y=1;z=1+
#=0-1+
#=7:T+
X=x*X;Y=y*Y;Z=z*Z
//approximate Fresnel, works better than the real thing when you don't want to tweak the IOR
f]x=X;y=Y;z=Z+
r=3:x*x+z*z+y*y+
d=6:T+
d=1-d*S/r+
d=d*d*d+
#=5:5+
#=d<#+
R=5#o+
d=d#1-d+
u=1#u+
v=1#v+
w=1#w+
D=D*d*u+
E=E*d*v+
F=F*d*w
//the handles
B]R=0+
#=X<8*3+
C=3#0
C]R=0+
#=X<8*4+
C=0#4
//red-Fresnel
2]R=f+
u=1/2;v=1/9;w=v
//white-Fresnel and the full moon
3]R=f+
u=7*9/p;v=u;w=v+
x=3*:+8+
z=U-x*p+p/2+
x=V-x*p-p/2+
r=3:x*x+z*z+
#=4<r/p+
D=D*I#D+
E=E*4/7#E+
F=F*2/5#F+
d=1/5#0+
A=A+D*d+
B=B+E*d+
C=C+F*d
//handle
4]R=5+
D=D*I;E=E*4/7;F=F*2/5
//light from the window
6]R=0+
#=P+
d=2#8*2+
A=A+D*d+
B=B+E*d+
C=C+F*d*I+
P=9
//carpet
7]R=o+
D=D/7+
E=E/3+
F=F/7
D]R=0+
#=8<Y+
C=0#3+
#=4:3*X-4*Z+
y=4:#/7+
#=#-y*7+
C=7#C
//reflector
5]R=0+
x=1;y=1;z=1+
#=0-1+
#=7:T+
X=x*X;Y=y*Y;Z=z*Z
//approximate Fresnel, works better than the real thing when you don't want to tweak the IOR
f]x=X;y=Y;z=Z+
r=3:x*x+z*z+y*y+
d=6:T+
d=1-d*S/r+
d=d*d*d+
#=5:5+
#=d<#+
R=5#o+
d=d#1-d+
u=1#u+
v=1#v+
w=1#w+
D=D*d*u+
E=E*d*v+
F=F*d*w
//the handles
B]R=0+
#=X<8*3+
C=3#0
C]R=0+
#=X<8*4+
C=0#4
//red-Fresnel
2]R=f+
u=1/2;v=1/9;w=v
//white-Fresnel and the full moon
3]R=f+
u=7*9/p;v=u;w=v+
x=3*:+8+
z=U-x*p+p/2+
x=V-x*p-p/2+
r=3:x*x+z*z+
#=4<r/p+
D=D*I#D+
E=E*4/7#E+
F=F*2/5#F+
d=1/5#0+
A=A+D*d+
B=B+E*d+
C=C+F*d
//handle
4]R=5+
D=D*I;E=E*4/7;F=F*2/5
//light from the window
6]R=0+
#=P+
d=2#8*2+
A=A+D*d+
B=B+E*d+
C=C+F*d*I+
P=9
//carpet
7]R=o+
D=D/7+
E=E/3+
F=F/7
D]R=0+
#=8<Y+
C=0#3+
#=4:3*X-4*Z+
y=4:#/7+
#=#-y*7+
C=7#C
```
-------------------------------------------
The last line, well, is the output filename. Just remember to throw in two ']'s and don't put a newline after it.
The last line, well, is the output filename. Just remember to throw in two `]`s
and don't put a newline after it.
```
]]example.ppm
```
]]example.ppm
thanks-for-fixes.md
+4 -4
View File
@@ -3576,9 +3576,9 @@ exists or can be read as that will be handled by the shell/program.
## [2013/hou](2013/hou/hou.c) ([README.md](2013/hou/README.md))
[Cody](#cody) fixed the Makefile so that this would work properly. Before this the use of
the program just did what the judges' remarks said as far as how it might
violate rule 2: the program is really just a decompressor to generate the
[Cody](#cody) fixed the Makefile so that this would work properly. Before this
the use of the program just did what the judges' remarks said as far as how it
might violate rule 2: the program is really just a decompressor to generate the
real source of the program. So the source of the entry has to be compiled and
then run, and the output has to be compiled to be `hou`. This allows the real
program to be used. Thus the Makefile rule looks like:
@@ -3602,7 +3602,7 @@ The `LDFLAGS` were updated to have `-lm` as the author suggested it uses the
`math.h` library which not all systems link in by default (Linux for instance
does not).
Further, after the file 2013/hou/doc/example.markdown was moved to
Further, after the file `2013/hou/doc/example.markdown` was moved to
[2013/hou/doc/example.md](2013/hou/doc/example.md) to match the rest of the repo
this broke `make` which Cody also fixed.