breakin

#NoEnv  ; Recommended for performance and compatibility with future AutoHotkey releases.
; #Warn  ; Enable warnings to assist with detecting common errors.
SendMode Input  ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir%  ; Ensures a consistent starting directory.

ox := 0
oy := 0

#Persistent
SetTimer, WatchCursor, 100

breakin

This is for cmake 3.12+ to retain old behaviour:

https://cmake.org/cmake/help/v3.13/policy/CMP0077.html?highlight=policy#policy:CMP0077

By adding the following lines to a root CMakeLists.txt it is easier to use it from another cmake project (using add_subdirectory).

if (POLICY CMP0077)
    cmake_policy(SET CMP0077 NEW)
endif()

breakin

Making a bit longer writeup here.

Lets say you restart rendering each time camera/objects moves. Ideal for a viewport in a 3d-editor when there is no animation happening.
Move a light source and you get noisy rendering that improves.

Lets say we want to do 256 samples per pixel, one at the time. We show result to user after each sample.

We construct a big table of blue noise for one pixel. Then we will scramble (that is the word used in papers) it somehow based on x,y to create different sequences for other pixels.

Think of a space that is wrapping in X but not in Y. X represents phi and Y theta on the hemisphere.

breakin

By adding the following small snippet at the top of markdeepToHTML markdeep can sortof support local file insertion when being run in node.js.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
function markdeepToHTML(str, elementMode, local_file_handler = undefined) {
    // If a local file handler is specified, resolve '(insert src here)' directly when possible'
    // Only expected to be used when run as script via node.js
    if (local_file_handler !== undefined) {
        str = str.rp(/(?:^|\s)\(insert[ \t]+(\S+\.\S*)[ \t]+here\)\s/g, function(match, filename) {
          var content = local_file_handler(filename);
          if (content === undefined) {

breakin

Lets pretend we have a 1d function f defined on x in [0,1] that we don't quite know, but we have a feeling for the general shape.
For x<0.5 it is often small, below 0.1. For x>0.5 it is higher, often close to 1.0.

Now we can break f into two functions on A=[0,0.5] and B=[0.5,1] and integrate them one at the time.
The sum of the two will be the integral of the entire range.

How many samples should we take for each of those two?
A key observation here is that if we get the integral on A 5% wrong that will be way worse than if we get the integral on B 5% wrong. Why? This is due to the fact that the integral over A will be much smaller than the integral over B, so it will contribute less to the full integral. If we place more samples in A or B we must compensate since they will have a different N-factor that we
divide with when we do the averaging.

breakin

First here is a nice derivation of beers law: http://www.applet-magic.com/beerslaw.htm

Say that the cube is one unit deep.
First lets say you see through the cube on a orthohonal ray where alpha = 0.33 everywhere.
We want 100-33=67% of the image from "behind" the cube to be seen through.

Let say that light enters from behind on our ray.
We will now pretend that "we" are the light so we do the traveling from behind.

We use beers law to solve this. It states

breakin

`       <img src="robot.jpg" width="128" border="2"/>`

<span style="color:#F00">HTML attributes</span>

breakin

export void simple(uniform unsigned int8 vin[], uniform unsigned int8 vout[], uniform int count) {
    foreach (index = 0 ... count) {
        unsigned int8 v = vin[index];
        // Do some calculations in 16-bit lanes. I expect v to be split in 2 registers
        unsigned int16 v2 = ((unsigned int16)v) * ((unsigned int16)v);
        // And somehow fold back into 8-bit lanes
        unsigned int8 m = v2>>8;
        // Write result
        vout[index] = m;
    }

breakin

So let us say that we want to do area lights.

We could either shoot at them on purpose (explicit) or just consider them if you happen to land on them (implicit).
Right now you are both using the implicit method which only works for very large light sources
(or for very sharp reflections if you do importance sampling of brdf).

In the explicit method you don't include contribution from emissive surfaces if you land on them
(except if you do so directly from the eye).
Instead you shoot a shadow ray towards that light from each point on your path traced path.
So you do get indirect lighting from them.

breakin

Think of a program as being put together from small "shaders". Each shader would correspond to a pure "function", or a task in a task-based system.
Each shader is compiled as a separate LLVM IR unit.
It could use clang for a subset of C/C++ with special requirements on the entry function.
In order to have big blocks and not too many pointers I think it would lend itself best towards data-oriented design ("batching") or something with memory arenas :)

When a shader is running in safe mode (debug, development etc) checks for all reads/writes are inserted into the LLVM IR so that each read/write is verified against bounds.
Once a shader it considered complete the extra bounds checks can be removed.

For example each shader can be given X input blocks with bounds (start, size).
Each write makes sure that no writes go into them, and no reads goes outside of those.