berkut

(A newly-hosted - February 2023 - re-creation of two blogs, one archived I used to have on blogspot/wordpress).

Although there are alternatives like using low discrepancy sequences (Halton, Sobol) which don't explicitly need the random number values generated from a PRNG itself which are used as well...

Thanks!

Erm, that likely depends on the industry you're in?

In HPC, branchless algorithms are often needed to use wide architectures (SIMD / GPUs) to their full capacity...

https://imgur.com/a/tJ8VRa5

It seems to think a Seal is a Penguin, although it is front-on and arguably could be a chick based off the colour, but...

Previous indications from Nvidia about their BVHs don't seem to show anything about very shallow trees for any of the BVH algorithms that OptiX supports (scroll to bottom for reverse visualisation of a BVH hierarchy on top of the Stanford Bunny model): https://drive.google.com/file/d/1B5fNRFwv2LsGlCBJ8oKYRiiDUtL...

So for Pixar/Dreamworks style things (look great, but not photo-real) they're useable and provide a definite benefit in terms of iteration time for lookdev artists and lighters, but it's not there yet in terms of high-end rendering at scale.

So it's often worth paying the penalty of having to sort rays/hitpoints into batches to intersect/process them more homogeneously, at least in terms of noise variance reduction per progression.

But very much depends on overall architecture and what you're trying to achieve (i.e. interactive rendering, or batch rendering might also lead to different solutions, like time to first useful pixel or time to final pixel).

It is slower to render than using "thin glass", and lighting the checkerboard surface underneath the glass isn't as efficient (you can't do naive Next Event Estimation through the refraction of the glass volume, but you can do manifold walks to solve that), but we do it at that level of fidelity often enough when required and have been for years. There are times when it's not required though, so approximations can be acceptable in more forgiving situations.

3.5" HDs of over > 20 MB for IBM PCs were around in IBM PCs at the time.

For shared_ptr, the atomic ref counting can cause surprising overhead due to contention in multi-threaded scenarios, even if just accessing the pointer, depending on how the shared_ptr is passed through functions...

After IE 6, things when downhill fast with the stagnation, but before that point, IE was a good browser.

i.e., I type 'cargo build', it compiles the single .rs I changed almost instantly, but then I'm staring at:

Building [=======================> ] 314/315: landscape(bin)

for the next 20 seconds.

lldb and mold (mentioned in article) are much faster.

Some of our dev builds actually are split up into separate .so files which is a bit slower at execution time, but means linking is a lot faster, especially when you want full debug info...

https://brickexperimentchannel.wordpress.com/2022/09/12/my-c...

He's also in Finland, so the cost of gear might not be as cheap as in the US.

> 140 colors just isn't enough—it's even less than the 8-bit color palette available on the original NES console

Is incorrect, as the NES didn't support 8-bit color... From Wikipedia:

"the console can display up to 25 colors simultaneously out of 54 usable colors"