bl0v3s blog - APL

making use of dyalog APL's isolates+futures in the the apl raymarcher

2024-05-02T00:00:00+00:00

overcoming nix specific issues to get isolates and futures to work</h1>

(skip to “actual implementation” below if this this isn’t of any interest to you)

Unlike I initially assumed just importing the isolate workspace on dyalog-apl retrived trough nix’s nixpkgs ( as I used that to produce these builds in a reproducible/declarative fashion) wasn’t directly feasible as upon loading the workspace I’d get some quite strange errors. Upon further debugging this issue I came to the conclusion that it was caused by the nix derivation for dyalog-apl rather than dyalog apl itself.

So after opening an issue and notifying the package maintainer at dyalog: isolates (parallel forEach and co) appear to be broken #316439</a> it seems as if they managed to fix it via dyalog: also apply patchelf to dyalog.rt #316495</a>

The issue basically boils down to the following:

As nix stores all binaries/libraries in /nix/store/<hash>-<path></code> packaging binary executables can be a litty funny at times. As obtaining the source code for dyalog-apl isn’t possible as for now were forced to work with the .deb/.rpm etc packages they provide. Which is exactly what the nix expression linked above does.

But just copying the contents of that .deb to /bin and /lib respectively isn’t all there is to it sadly as binary packages already have pre definedELF headers</a> these make assumptions about the names and locations of the library components to be loaded upon executing the elf by the linux kernel.

like mentioned in the issue the maintainer forgot to also add ncurses to dyalog.rt</code> luckily as the elf specification is simple enough

to alter using tools such as patchelf</code>, which is very frequently seen when packaging binary packages for nix/nixos.

Thus everything required to do was changing

patchelf</span></span> $</span>{</span></span>dyalogHome</span></span>}</span></span>/dyalog --</span>add-needed</span> libncurses.so</span>
</span></code></pre>
to</p>
for</span> exec in</span> "</span>dyalog"</span></span> "</span>dyalog.rt"</span></span></span>;</span> do</span>
</span>     patchelf</span></span> $</span>{</span></span>dyalogHome</span></span>}</span></span>/$</span>exec</span></span> --</span>add-needed</span> libncurses.so</span>
</span>done</span>
</span></code></pre>
within the nix expression. Which the maintainer did an awesome job of figuring out see</a></p>
Thus using the package with the previous expression running ldd would result in</p>
linux-vdso.so.1 (0x00007ffff7fc6000)
</span>libm.so.6 => /nix/store/k7zgvzp2r31zkg9xqgjim7mbknryv6bs-glibc-2.39-52/lib/libm.so.6 (0x00007ffff7edd000)
</span>libpthread.so.0 => /nix/store/k7zgvzp2r31zkg9xqgjim7mbknryv6bs-glibc-2.39-52/lib/libpthread.so.0 (0x00007ffff7ed8000)
</span>libdl.so.2 => /nix/store/k7zgvzp2r31zkg9xqgjim7mbknryv6bs-glibc-2.39-52/lib/libdl.so.2 (0x00007ffff7ed3000)
</span>libc.so.6 => /nix/store/k7zgvzp2r31zkg9xqgjim7mbknryv6bs-glibc-2.39-52/lib/libc.so.6 (0x00007ffff7213000)
</span>/nix/store/k7zgvzp2r31zkg9xqgjim7mbknryv6bs-glibc-2.39-52/lib/ld-linux-x86-64.so.2 => /nix/store/k7zgvzp2r31zkg9xqgjim7mbknryv6bs-glibc-2.39-52/lib64/ld-linux-x86-64.so.2 (0x00007ffff7fc8000)
</span></code></pre>
while using the fixed drv with ncurses being added to the elf header would result in</p>
linux-vdso.so.1 (0x00007ffff7fc6000)
</span>libncurses.so => /nix/store/zcjy82jk8i8y1cvvzaadj5wiz41gvp53-ncurses-abi5-compat-6.4/lib/libncurses.so (0x00007ffff7f58000)
</span>libm.so.6 => /nix/store/k7zgvzp2r31zkg9xqgjim7mbknryv6bs-glibc-2.39-52/lib/libm.so.6 (0x00007ffff7e75000)
</span>libpthread.so.0 => /nix/store/k7zgvzp2r31zkg9xqgjim7mbknryv6bs-glibc-2.39-52/lib/libpthread.so.0 (0x00007ffff7e70000)
</span>libdl.so.2 => /nix/store/k7zgvzp2r31zkg9xqgjim7mbknryv6bs-glibc-2.39-52/lib/libdl.so.2 (0x00007ffff7e6b000)
</span>libc.so.6 => /nix/store/k7zgvzp2r31zkg9xqgjim7mbknryv6bs-glibc-2.39-52/lib/libc.so.6 (0x00007ffff7213000)
</span>/nix/store/k7zgvzp2r31zkg9xqgjim7mbknryv6bs-glibc-2.39-52/lib/ld-linux-x86-64.so.2 => /nix/store/k7zgvzp2r31zkg9xqgjim7mbknryv6bs-glibc-2.39-52/lib64/ld-linux-x86-64.so.2 (0x00007ffff7fc8000)
</span></code></pre>
note libncurses.so => /nix/store/zcjy82jk8i8y1cvvzaadj5wiz41gvp53-ncurses-abi5-compat-6.4/lib/libncurses.so (0x00007ffff7f58000)</code> being present now after applying the fix</p>
So until that PR/commit is merged into nixpkgs I’d have to specify:</p>
{</span>
</span>  inputs</span> =</span> {</span>
</span>    nixpkgs</span> =</span> {</span>
</span>      url</span> =</span> "</span>https://github.com/TomaSajt/nixpkgs.git"</span></span>;</span>
</span>      type</span> =</span> "</span>git"</span></span>;</span>
</span>      rev</span> =</span> "</span>0ea7fe9f11803bea5fd9f6b2ecd96fd96b0731e7"</span></span>;</span>
</span>    }</span>;</span>
</span>    # other inputs ...</span>
</span>  }</span>;</span>
</span>}</span>
</span></code></pre>
within my flake.nix expression used to build this project. If you aren’t using nix but the rpm/deb
package youd of course not have to do this.</p>
Another approach of solving this issue would be using buildFHSEnv</a>
which I would have done if me or the maintainers couldn’t figure out how to fix this
in time.</p>
As buildFHS env uses Linux’ namespaces feature to create temporary lightweight environments which are destroyed after all child processes exit, without requiring elevated privileges. It works similar to containerisation technology such as Docker or FlatPak but provides no security-relevant separation from the host system</em></p>
this implies the presence of a namespace enabled linux kernel which would break nix’s excellent
macos/darwin support as well as nix on non namespace enabled linux systems. So in order to keep
the majority of nixpkgs functional on macos and non-nixos systems
(by the way nix is availible in the debian/arch repos by default)</em>  patchelf is generally to be favored.
But in especially nasty cases such as where precompiled (e.g nonfree packages such as steam lets say)
packages are expecting certain binaries or files in general to be present in /sbin/</strong> , /bin/</strong> or
/usr/bin</strong> and the files are sourced at runtime rather than via the elf header upon program load.
buildFHS would have to be used as thats a better approach than trying to binary-patch the hardcoded
references within the compiled software.</p>
actual implementation</h1>
Since this commit</a> multithreading is now availible</p>
While at the time of writing this the amount of theads is hardcoded via threads←4</code> in flake.nix but you are free to changing
the amount of threads by either altering the raymarcher.apl</code> file or the flake.nix file accordingly (see flake.nix to see what variables need to be applied).
Thus rendering with much more than 4 threads is totally feasible and it does seem to be able to truly utilize all resources given to it perfectly fine.</p>
See (rendering in 4K):</p>

(TODO actually explain how this was pulled off. Until then check raymarcher.apl</code>’s comments that were added in the commit linked above</p>

Raymarching meets dyalog APL 2024-04-28T00:00:00+00:00 code</h1> source code</h2> As for now I only provide build expression through nix which alongside the source-code are located at this github repository</a>. NOTE: Since this commit/relase</a> multithreading is now officially supported. Though this page was written before I added support for that running it yourself</h2> Currently the build targets/instructions are supplied via (nix)[https://nixos.org/] as it provides a quick, declarative and reproducible way to build this project but the build instructions can easily be derived from the flake.nix file located in the root directory of the repository linked above. Thus: running under nix</h3> nix run github:bolives-hax/apl-raymarcher#pngRunner --no-write-lock-file # output will we placed in cwd as rendering.png </code></pre> (take a look at the repositories README.md or flake.nix file for further targets/runners) implementation details</h1> so how does it work?</h2> With ray marching works pretty similar to ray tracing, but instead of checking if our ray intersects with object’s exposed surface through the means of algorithms such as the Möller–Trumbore intersection algorithm</a>. We instead use something called signed distance functions</a> or short “SDF” ’s. Essentially signed distance functions/SDFs are functions taking a given point in space p</code> as their input parameter returning the distance from the given point p</code> and the geometry it defines. For example the SDF for a sphere would look something like this (in GLSL) float sphereSDF(vec3 p, float radius) { # length() gets the length of its arguments vector length(p) - radius; } </code></pre> Essentially taking the length of a point spanned from one point to another. As in some point along the ray originating from our camera subtracted by the radius of a sphere. Tells us how far away that sphere (with the given radius) is from the supplied point (passed as vec3 p in this example). A possible implementation of said SDF in APL may look like this: (Taken from my implementation): ball_sdf←{ (length ⍵) - ⍺ } </code></pre> with the length</code> function being supplied through: ⍝ ⍺ =2 would mean the squareroot sqrt←{⍵*÷⍺} length←{2 sqrt (+/{⍵*2}¨⍵)} </code></pre> NOTE: As its called signed distance function instead of just distance function or usigned the values returned make use of (signed number representation)[https://en.wikipedia.org/wiki/Signed_number_representations]. What this means in practice is assuming lets say we’d run it against a point contained within the sphere defined by the function above: (0.5) ball_sdf((0)(0)(0)) </code></pre> we’d get a negative return value of ¯0.5</code> using a point such as (0.28 0.28 0.28)</code> instead which is pretty much on the edge provided by the diameter/radius of said sphere like: (0.5) ball_sdf((0.28)(0.28)(0.28)) </code></pre> wed get ¯0.01502577388</code> as the length of (0.28 0.28 0.28)</code> which roughly equates to 0.48497...</code>. What we can essentially derive from that information is: if sdf(p)</code> is positive, p lays outside of sdf</code></li> if sdf(p)</code> is negative, p lays within sdf</code></li> if sdf(p)</code> is very close to +-0 as in lets say sdf(p) < 0.0001</code> p</code> lays on the edge or within sdf()</code></li> </ul> Ok but how do we go from having a SDF to actually approximating where and if object is hit=visible? Luckily that is quite simple to do. First we need to define some variables though Assuming the function res supplies the horizontal and vertical resolutions as (x y) res←↑(get_res drawer ( 0 0 ))[2] xres←(res)[1] ⋄ yres←(res)[2] cam_origin←(0 0 ¯1) </code></pre> As we now have the dimensions of image/frame we intend to render. We map each pixel onto a 2 dimensional plane to then cast a ray through each respectively mapped pixel coordinate (x,y)</code>. There are various ways to represent our pixel/plane-coordinate mapping. In my approach I first span a map going from (0,0)</code> to (1,1)</code> and offset that to (-0.5,-0.5)</code> to (0.5) (0.5)</code> as I prefer that notation. One way of implementing this would be through xy←{((⍳(xres))-1)⍵}¨((⍳(yres))-1) _uv←{(⊃⍵[1]÷xres) (⍵[2]÷yres)}¨xy uv←_uv-0.5 </code></pre> This illustration further outlines the process underwent Before we can then run our SDF’s against the rays cast through the 2d pixel/plane-coordinate mapping one should also apply the so called aspect ratio</a> through: uv←{⊃((⍵[1] ÷ (xres ÷ yres)) ⍵[2])}¨uv uv_vecs ← ⊃,/{y←⍵[2] ⋄ {⍵ (-y)}¨(⊃⍵[1]) }¨uv </code></pre> With the pixel/plane-coordinate mapping in place and the aspect ratio being corrected. Generating rays is as simple as: { x←⍵[1] y←⍵[2] cam_dir←norm x y 1 rgb cam_dir t }¨uv_vecs </code></pre> The code above would emit an array of normalized directional vectors with the respective (x y)</code> pixel/plane-coordinate mapping being apply the the vectors x</code> and y</code> directional components. This along with the camera origin would provide the basis for our camera model. In my renderer the function rgba lays the basis to converting ray vectors to actual color values. Now casting the ray is done using the abstract below rgb cam_dir t </code></pre> where cam_dir</code> is the vector with the directional components described above and t</code> denoting time (while not implemented yet one could reference the t</code> variable if one wanted to render an animated scene). Though you may ask yourself: why is it called ray marching? Like where is the actual “marching” taking place? And why do we even need to march in the first place? Isn’t using that SDF by itself enough? Well essentially what would happen if you had lets say 2+ objects and the ray would come quite close to one object initially but then still pass by. Not actually intersecting the objects surface and maybe hit another object. As the SDF would still return the distance of the closest object (See below) (TODO add a better ilustration) this wouldn’t tell us too much. The SDF by itself doesn’t respect the rays direction but just provides a mere distance estimate. As you can see the distance it determines can represented in a fashion resembling the radius of a sphere. Meaning it only tells us the distance from one point to another point but not if it actually lays along a ray. In order to accommodate for this issue. We essentially to approach the point we plan intersect in a step-wise manner. The smaller the lowest possible distance grows, the smaller further steps undertaken would be. If the distance is approaching 0 (getting very close to it) . We’d register that as a hit. Otherwise we would step on until either the max step count is reached or the maximum distance is exceeded. The marching function is called from the rbg</code> function described above, at the time of writing this it looks like this: ⍝ ⍵ = [ cam_dir time bg ] rgb←{ cam_dir←⊃⍵[1] time←⊃⍵[2] d←(( 0 cam_origin cam_dir 35 100) march 0) hit←d[1] ⍝ phong ( total_dist , ro , rd , obj) hit: phong ((d[2]) cam_origin cam_dir (d[3])) ⍝ not hit (render background) (sky cam_dir[1] (0 ⌈ ((cam_dir[2])+0.12))) } </code></pre> Essentially d←(( 0 cam_origin cam_dir 35) march 0)</code> is where the magic happens. Our march function will march along cam_dir</code> vector, starting from cam_origin</code>. The 35</code> denotes the maximum of 35</code> steps which will be taken. Of course that can be adjusted. For example rendering reflections should get away using a lower maximum step count, as less precision is needed there I figured. 100</code> denotes the maximum distance objects can have from the ray origin (camera) . So we render objects up until the vector length of 100.0</code> from the camera. While technically not needed, if we omitted this wed always take 35</code> or whatever out max step count is set to until giving up. This reduces the amount of unnecessary computations needed. The first argument of march</code> is the distance stepped so far. We initialize this with 0, as march internally calls itself in a self referencing fashion with the distance value increasing when its supplied as the first parameter in further self referencing calls to march</code>. The argument on the right most side of march is the stepcount</code>. We also initialize this with 0 as march will every time it calls itself increment that by one. march</code> first return value returns either 0</code> or 1</code> as in (hit,...)</code> which is inspected before accessing the further return values, such as the distance d[2]</code> or the respective id of the object hit d[3]</code>. Further processing of march</code>’s return values is bound to that first hit</code> value. Since if march never hit anything, we couldn’t return anything in these fields and thus it would be pointless to work with them. Assuming hit=1</code> as in true wed call the phong</code> function which would apply the phong shading model</a> taking as its last parameter the id of the object hit. As knowing that we can from within phong</code> apply different “material” properties by using different light absorption/reflection attributes in accordance with the phong shading model. If nothing was hit the sky</code> function will be called returning the r g b components of the background for the given point. Now lets dissect the march function to gain a better understanding of it: ⍝ ⍺ = [ total_dist , ro , rd , max_steps, max_dist ] ⍝ ⍵ = stepcount march←{ total_dist ← ⍺[1] ro ← ⊃⍺[2] rd ← ⊃⍺[3] max_steps ← ⊃⍺[4] max_dist ← ⊃⍺[5] r ← sdf ( ro + rd × total_dist ) dist ← r[1] obj ← r[2] ⍝ if we exceeded the maximum amount of steps return 0 ⍝ AND we exceeded the maximum distance from the ray origin=( eg cam pos/point of reflection) return 0 ⍝ TODO use dist to simulate fog by adding some fog color value based on the distance ⍵<max_steps ^ dist < max_dist: { dist < epsi: (1 (dist + total_dist) obj ) ( (dist + total_dist) ro rd max_steps max_dist) march ⍵ } ⍵+1 (0 0) } </code></pre> I believe the abstract is pretty self explanatory but in essence r ← sdf ( ro + rd × total_dist )</code> is of most interest. All SDF’s at least take one parameter p</code> which denotes the point in space the signed distance function returns the respective distance to. In order to “march” we must progress our directional vector rd</code> derived through the pixel mapping above by the total_dist</code> factor to get the current distance to run our intersection-range checks against. This needs to be added to the camera origin positional vector ro</code>. We could also leave ro</code> out but then our camera would be restricted to being located at 0 0 0</code>. But to deliver more flexibility here and as the march function is used in other places within this program (for example for marching along reflection rays which start from the surface we reflected from) . So its generally better to add ro</code> here. We could for example set r</code> to the ball_sdf←{ (length ⍵) - ⍺ }</code> function as showcased early on in this article. ⍵</code> denotes the point p</code> in this case ro + rd × total_dist</code> while ⍺</code> represents the radius of the sphere. Were not limited to a single sphere sdf. Of course one could also combine multiple sdf’s through use of the ⌊</code> > minimum operator. For example showing 2 spheres. One in the center of our scene and one located at y=+1</code> through defining/calling: (ball_sdf (p - (0 0 0)) ⌊ (ball_sdf (p - (0 1 0)) </code></pre> This works as it would return the distance to the sphere closest to us. (-sdf1) ⌈ (sdf2)</code> could be used to carve out the first geometry defined by the first sdf from the second one NOTE: this “-” sign is required here. Likewise using (sdf1) ⌈ (sdf2)</code> max would instead return only the points where sdf1</code> intersects with sdf2</code>. There are lots of tricks that can be used when working with signed distance functions. But it should already be clear that even with just min and max and + and - one can compose some pretty complex geometry. Now I will focus on the call to the phong</code> function seen before in rgb</code>. rgb</code> has the section: hit: phong ((d[2]) cam_origin cam_dir (d[3])) </code></pre> which essentially runs phong</code> with the parameters ⍝ ⍵ = [ total_dist , ro , rd , obj] </code></pre> The start of phong</code> is structured like this: ⍝ ⍵ = [ total_dist , ro , rd , obj] phong←{ total_dist←⊃⍵[1] ro←⊃⍵[2] rd←⊃⍵[3] obj←⍵[4] p←ro + rd × total_dist l1←{ ambient_color←checkers_ball p diffuse_color←0.5 0.5 0.5 specular_color←0.1 0.1 0.1 alpha←0.7 light_intensity←⍵ ambient_color diffuse_color specular_color alpha light_intensity } 0.5 ⍝ ... further lights lightPos←3 3 0 ⍝ hardcoded here but could ofc be passed via ⍵[5] </code></pre> l1</code> defines a light locally. In my case phong</code> defines l1</code> - l7</code>. Instead of trying myself at explaining what ambient_color←checkers_ball p diffuse_color←0.5 0.5 0.5 specular_color←0.1 0.1 0.1 </code></pre> does. I will just include a picture that gets the point across following lightPos</code> seen above comes ⍝ checkered ball ⍵=scene_obj1_ball: l1 phongLight p ro ⍝ octahedron ⍵=scene_obj2_octa: l2 phongLight p ro ⍝ blob ⍵=scene_obj3_melted_balls: l3 phongLight p ro ⍝ floor ⍵=scene_obj4_floor: (l4 phongLight p ro) + (4 checkers ((p[1]) (p[3]))) ⍵=scene_obj5_frame: (l5 phongLight p ro) ⍵=scene_obj6_ball: (l6 phongLight p ro) + ( 0.5 × (0.11 checkers ((p[1]) (p[2])))) ⍵=scene_obj7_torus: (l6 phongLight p ro) + ( 0.5 × (0.22 checkers ((p[1]) (p[2])))) ⍵=scene_obj8_rounded_box: reflective_material ( p rd ro scene_obj8_rounded_box l7) </code></pre> assuming of course the scene_objX_NAME</code>-type variables are defined somewhere accessible. In my case globally like shown below. Note that there is no catchall/default expression. I intentionally chose this so I don’t accidentally forget handling each defined object individually. But you could of course just write something like: ⍵=scene_objX_NAME: (l_X phongLight p ro) (l_default phongLight p ro) </code></pre> With (l_default phongLight p ro)</code> being applied for any unmatched object. phongLight</code> takes the as its left-side parameter whats defined above by l1</code>-l7</code> and as the parameters on the right p</code> and ro</code>. ro</code> in this case provides the position of the camera and p</code> being the point on a surface march</code> detected an intersection with. Based on that information, phongLight</code> returns a color in the (r g b)</code> (float float float) specification. Please note that as ⍵=scene_obj8_rounded_box</code> is a little special special I will document it later on. As its the only object with reflective properties in the scene. scene_obj1_ball←1 scene_obj2_octa←2 scene_obj3_melted_balls←3 scene_obj4_floor←4 scene_obj5_frame←5 scene_obj6_ball←6 scene_obj7_torus←7 scene_obj8_rounded_box←8 </code></pre> Knowing the object id in ⍵</code> is quite useful here, as it allows us to apply phong shading or even textures/reflection properties on various objects individually. If we were to omit it, wed either have to calculate it again by throwing p</code> back into in the sdf’s again or we would have to assign the same texture and phong shading properties to every object. So now lets look at phongLight</code>: The picture below should provide some hints of what is going on in there ⍝ ⍺ = [ ambient_color(rgb), diffuse_color(rgb), specular_color(rgb), alpha, light_intensity ] ⍝ ⍵ = [ p ro ] phongLight←{ p←⊃⍵[1] ro←⊃⍵[2] ⍝ TODO REMOVE 0.5 (DEBUG) ambient_color←(⊃⍺[1]) × 0.5 diffuse_factor←⊃⍺[2] specular_factor←⊃⍺[3] alpha←⊃⍺[4] light_intensity←⊃⍺[5] ⍝ estimate the normal vector at point p on the surface n ← estNormal p ⍝ light position ( TODO don't hardcode up here ) light_pos←((0) (3) (1)) ⍝ vector between the point on the surface and the light position l← norm ( light_pos - p) ⍝ vector between the point on the surface and the view/camera/etc vector v← norm ( ro - p) ⍝ vector reflecting the light-surface vector on the estimated surfaces normal vector r← norm ( (-l) reflect n ) ⍝ dot product of both dotln ← l dot n dotrv ← r dot v ⍝ the light doesn't hit the surface at any relevant angle dotln < 0.0: 3 ⍴ 0.0 c ← ambient_color + { ⍝ angle not in range for specular effect, just apply diffuse color ⍵ < 0.0: diffuse_factor × dotln ⍝ angle in range for specular effect, apply diffuse and specular colors diffuse_factor × dotln + specular_factor × ( dotrv × alpha ) } dotrv light_intensity × c } </code></pre> Essentially based on what angle we look at the surface from and the position of a light we can determine if a specular effect should be present or rather just the diffuse lighting effect alone. Or if the light sources rays never even hit the object in the first place. Based on if any of the 3 cases (not hit, hit diffuse, hit specular) we apply these effects Now to scene_obj8_rounded_box:</code> which is special in the sense that it doesn’t just apply phong shading but also simulates a reflective surface. What essentially happens here is that if obj=scene_obj8_rounded_box: reflective_material</code>, meaning the rounded box “8” got hit by a ray cast from the camera. Instead of applying phong shading like we do with the other objects. Whats being done here is that similar to how its done when applying phong shading. We take into account from what angle were looking at the object from. Using the estimated normal vector of the point on the surface the camera ray is pointing at and the view angle we can reflect the ray accordingly. So knowing what the vector/ray direction after being reflected allows us to do the following: We essentially do the same as what we did when casting rays from the camera upon non reflective objects. But instead of the ray origin being the camera and the ray direction being determined through which pixel on our plane it goes, the ray origin is the position our ray originating from the camera hit the reflective surface at. Likewise we use the reflected directional vector as our new directional vector. One could think of it roughly as us moving the camera to the point were reflecting from</del> . using this new information we then undergo the marching loop once again by calling the march</code> function. Note that the maximum step count was reduced to 20 and the maximum distance to 40 as reflections generally need less accuracy. IMPORTANT DETAIL: note the line specifying ref_surface_p ← ref_surface_p + ref_surface_n × 0.005</code> makes up a VERY!! very important detail. Basically what happens here is that we shift the origin we use when casting the reflected ray by a tiny bit forward (towards the normal vector of the surface) to avoid it intersecting with itself. Whats left is performing phong shading on the object initially hit not the reflection. To then combine that with the color values returned after performing the reflection. As otherwise wed have a perfect mirror though (you likely couldn’t tell its a mirror). So in order to be able to tell it apart as a reflective surface it can’t perfectly reflect everything and needs to perform some sort of modification to the colors it reflects. As for now l7</code> gives it a slightly yellow tint. The line doing that job is essentially col_obj_self← (light phongLight ref_surface_p ro )×0.3</code> and at the return segment hit: ((t ref_reflected_final)×0.7) + col_obj_self ⍝ nothing hit, thus apply background accoring to the reflected vectors orientation ((sky (ref_reflected_rd[1]) (0 ⌈((ref_reflected_rd[2])+0.12)))×0.5) + col_obj_self </code></pre> reflective_material←{ ref_surface_p ← (⊃⍵[1]) ref_view_rd ← (⊃⍵[2]) ro ← (⊃⍵[3]) obj_self← (⊃⍵[4]) light ← (⊃⍵[5]) ⍝ normal vector of the point we hit the surface at ref_surface_n ← estNormal ref_surface_p ⍝ IMPORTANT !!! V ⍝ slightly offset the origin to cast the reflected ray from in the direction of the reflecting surfaces ⍝ normal vector (which will always point away from it) ref_surface_p ← ref_surface_p + ref_surface_n × 0.005 ⍝ reflect the camera to reflective surface vector using the surfaces normal vector at that position ref_reflected_rd ← norm ( ref_view_rd reflect ref_surface_n ) ⍝ initiate raymarching once more but this time starting from the reflecting surface ⍝ using a slightly reduced step count/max distance ref_reflected_final ← ( 0 ref_surface_p ref_reflected_rd 70 150) march 0 ⍝ 1 if the reflected ray hit anything, otherwise 0 hit←(ref_reflected_final[1]) t←{ dist←⍵[2] obj_is_self← (⍵[3])=obj_self ⍝ object intersected with itself ( should never happen for now just color it in a vibrant ⍝ green soits easy to debug or maybe throw an exception obj_is_self: ( 0 1 0) ⍝object didn't intersect with itself, apply phong shading at the point the reflection ray hit at phong (dist ref_surface_p ref_reflected_rd (⍵[3])) } col_obj_self← (light phongLight ref_surface_p ro )×0.3 ⍝ V phong shading at the point the reflection hit at hit: ((t ref_reflected_final)×0.7) + col_obj_self ⍝ nothing hit, thus apply background accoring to the reflected vectors orientation ((sky (ref_reflected_rd[1]) (0 ⌈((ref_reflected_rd[2])+0.12)))×0.5) + col_obj_self ⍝ TODO ^ instead of using these hardcoded values allow the user to specify the factor of what ⍝ rgb components get reflected more and make it bound to distance. For now this is too ⍝ enhance obj reflecitons while not reflecting the background too much but thats ofc just a hack } </code></pre>