#hlsl

Nah girlie's running on the unity engines CG/HLSL shader language. The trick is to instead of generating the curve, and placing the segments with that info, we repeat the process that forms the dragon curve backwards. A dragon curve starts with a single segment, and it has 1 mid point. When folded, it turns into 2, and has 2 midpoints.

So what we do is we test every pixel, find its closest hypothetical midpoint, and then perform the transformation backwards. Since they originate from one segment, and this method ends up halvening the midpoints each time by merging them on top each other. These means after your desired number of iterations, we can simply check to see if the pixel we were on collapsed back into a specific midpoint.

Making midpoints integers an example would be the line segment from (0,0) to (0,2). Well then im that case the midpoint would be (0,1).

This scaling even allows us to keep track of everything via modulo operations. The vector math ends up working out so that most the time you're rotating and scaling, but the net displacement from the two is a fixed size vector along the cardinal direction, which when converted to integer math, is the same as either adding xor subtracting, just 1 from your current x xor y coordinate, based on the direction the rotation would take it

We can add a color gradient by keeping track of the turns in the curve. I dont remember exact details but its literally as simple as left? 0: right? 1. And then converting that binary number to decimal it gives you what number along the curve that pixels nearest midpoint belonged to.

Now there are some tricky edge cases like 0 iterations, or the first and last segment only being one line segment instead of a curve. Additionally if we try to smooth the color a bit by sampling all 4 directions, we'd get color bleeding between two very different parts of the curve that have been folded into proximity. You could probably weight this based on the proximity between segments but i dont recall if i ever bothered.

Physically based or inspired lightning is not feasible to implement in interactive applications such as games because of the iterative nature of its algorithms, which makes them computationally expensive.

Accurate lightning simulation is described with the Dielectric Breakdown Model (DBM), which involves solving Laplace’s equation. Solving it with the conjugate gradient method (CGM) has been proven to be computationally expensive, however, this method has been substituted with a rational function to produce faster results. Additionally, these methods have been tested in single-threaded CPU applications, but there’s evidence that the CGM can be optimized if they are computed in parallel in the GPU.

This research attempts to prove whether it’s possible to optimize physically inspired lightning generation performance using a rational function method in the GPU with the aid of parallel multithreading.

The application is developed in C++ using the Direct3D 11 API. It ports open-source code of the CGM and rational method from OpenGL to D3D11. Testing is carried out using a performance benchmark measuring the computation times of the parallelized rational method using a compute shader against its non-parallelized version and the CGM.

Despite the embarrassingly parallel nature of the algorithm, the parallelized version was 3 times slower than its non-parallelized version, albeit 3 times faster than the CGM. Resources consumed by the rational method increased ninefold compared to its non-parallelized version as well.

In conclusion, the parallelized version proved to be slower due to the CPU-GPU data transfer overhead. Further research hypothesis suggests the use of group shared memory could compensate for this overhead.

Personally I would've loved to have more time to work on this as I believe I could've proved my hypothesis with group shared memory, but I'm not as knowledgeable yet. I need to study more graphics programming!