Jan Walter R&D

Blender to Arnold Export - Part IV: Blender 4.0 Splash Screen

2023-11-27T00:00:00+00:00

The last part (Blender to Arnold Export - Part III: Base Color</a>) talked about exporting some color information (from Blender</a>) instead of using full materials/shaders. So basically the light sources are still not taken into account. But can we export the latest Splash Screen</code> (for Blender 4.0</code>) toArnold</a>?

The image above was rendered by Cycles</a>. I had to modify the Python</a> code a bit to export the camera in case it's not part of a Collection</code>.

...</span>
class</span></span> AssExporter</span></span>:</span></span>
    def</span></span> __init__</span></span></span>(</span></span>self</span>)</span></span>:</span></span>
        self</span>.</span>filename</span></span> =</span> None</span>

    def</span></span> export</span></span></span>(</span></span>self</span>,</span> context</span>,</span> filename</span>,</span> use_shader_file</span>,</span> use_shader_file_only</span>)</span></span>:</span></span>
        def</span></span> exportMaterials</span></span></span>(</span></span>)</span></span>:</span></span>...</span>
        def</span></span> exportCamera</span></span></span>(</span></span>)</span></span>:</span></span>...</span>
...</span>
            print</span></span></span></span>(</span>'</span></span></span>DEBUG: export collections ...'</span></span></span>)</span></span>
...</span>
                            if</span> me</span></span> is</span> None</span>:</span></span>
                                if</span> ob</span>.</span>type</span></span> ==</span> '</span></span></span>CAMERA'</span></span></span>:</span></span>
                                    if</span> ob</span>.</span>name</span></span> ==</span> camera_name</span></span>:</span></span>
                                        exportCamera</span></span></span></span>(</span>)</span></span>
...</span>
        if</span> not</span> camera_exported</span></span> and</span> len</span></span></span></span>(</span>bpy</span>.</span>data</span>.</span>cameras</span></span>)</span></span> >=</span> 1</span>:</span></span>
            #</span> camera was not part of a collection
</span>            objects</span></span> =</span> bpy</span>.</span>data</span>.</span>objects</span></span>
            for</span> i</span>,</span> ob_main</span> in</span></span> enumerate</span></span></span></span>(</span>objects</span></span>)</span></span></span>:</span></span>
                obs</span></span> =</span> [</span>(</span>ob_main</span></span>,</span> ob_main</span>.</span>matrix_world</span></span>)</span></span>]</span></span>
                for</span> ob</span>,</span> ob_mat</span> in</span></span> obs</span></span></span>:</span></span>
                    if</span> ob</span>.</span>name</span></span> ==</span> camera_name</span></span>:</span></span>
                        print</span></span></span></span>(</span>'</span></span></span>DEBUG: export camera ...'</span></span></span>)</span></span>
                        exportCamera</span></span></span></span>(</span>)</span></span>
...</span>
</span></code></pre>
The current source code can be found on
Codeberg</a>. The
Python source code is probably changing with the latest Blender
releases, whenever I feel the need to render at least a similar scene
with Arnold.</p>
</p>
This is it for now. On the TODO</code> list is being aware of subdivision surfaces</code> during the export and taking lights</code> into account (which
needs also proper materials/shaders</code>).</p>

Guerilla 2.3.43 is Here! 2023-10-04T00:00:00+00:00 Guerilla Render</a> is not really on my R&D list anymore, but it's worth mentioning at least the latest releases, because they offer one free connected licence for everyone, including commercial usage. Here just one of my test scenes (which originally comes from Radiance</a>) rendered by the latest Guerilla Render release (version 2.3.43): The Conference Room scene is available at least in Blender</a> file format from my export_multi</a> GitHub repository. Like for most other standalone renderers you can export .obj files from within Blender, import the geometry, and define and assign the materials within the standalone application. For convenience I still have a 3 year old file on my render_comparison</a> GitHub repository, which was used to render with the latest Guerilla Render release (see screenshot above). Use Python and Qt for a Skat game helper 2023-09-20T00:00:00+00:00 This blog starts a series about using Python</a> to implement some helper programs to learn the German Skat</a> game (and keep track of things). Reading the rules on Wikipedia is a good introduction and gives you an overview, but to learn how to play the game I can recommend the Skat Island</a>. So here is how a simple helper app might look like to keep track of which cards where played: I have written such an app in Python using the Qt</a> library for the graphical user interface (GUI). To get started with Qt for Python</a> read the official documentation. But back to the screenshot above. The idea is to keep track of the cards which were played already, while playing a game (online or for real) with two other players. The variant above was written to first choose one of the supported varieties (see Wikipedia</a> article), suit</code>, grand</code>, or null</code>, of the game. In addition to those there is an unofficial variety, called Sächsische Spitze</a>, which is similar to grand</code>, just with reversed order. So on the left you see the jacks</code>. If you click on one of the top two jacks you will select the grand</code> variant, the other two (lower) jacks select the Sächsische Spitze</code>. For a suit</code> game select one of the aces</code> (to the right of the jacks</code>). Because there are four suits, Clubs</code> (♣), Spades</code> (♠), Hearts</code> (♥), and Diamonds</code> (♦), it matters which of the aces you clicked. For the last variant, null</code>, just click one of the sevens (7</code>), which one doesn't matter. After selecting the variant of the Skat game, all cards get visible (ordered for a suit</code> game), and you can click individual cards to flip them: In the screenshot above I clicked the Queen</code> of Hearts</code> (♥), so it becomes invisible again. After having clicked all cards (and made them invisible), the situation is pretty much the same as when you started the helper program. The first version of my Python program had a slightly different purpose, which I will explain later, but I'm working on a new version, which introduces counters to keep track of how many points each individual player has collected while playing out tricks</code>. The screenshot above shows the situation after the first trick</code> was played (for a Clubs</code> suit game) and the full print out (to the shell or console where you started the Python script) looks like this: $ ./skat_new.py Clubs 2 ♣ ['J♥', 'J♠', 'A♦'] [0, 15, 0] 3 ♦ ['Q♦', '10♦', '7♦'] [0, 15, 13] 1 ♥ ['Q♥', 'A♥', '8♥'] [14, 15, 13] 1 ♠ ['A♠', 'K♠', '9♠'] [29, 15, 13] 1 ♣ ['J♦', '7♣', '7♠'] [31, 15, 13] 1 ♣ ['Q♣', '8♣', '7♥'] [34, 15, 13] 1 ♦ ['K♦', '8♦', '8♠'] [38, 15, 13] 2 ♦ ['9♦', '9♣', '10♠'] [38, 25, 13] 2 ♣ ['J♣', '10♥', 'K♣'] [38, 41, 13] 2 ♣ ['A♣', 'K♥', '10♣'] [38, 66, 13] tricks: [ 5, 4, 1] scores: [ 38, 66, 13] skat: [ 3] </code></pre> So, while clicking away cards, which were played out, the program knows a little bit about the rules, knows which variant (in this case Clubs</code> for the suit</code> game), was chosen, and adds the values of each trick to the winner's counter, so it also knows how to detect, who won the trick. Because the source code is still under development, I'm not showing the entire Python code (or making it public yet), but here is how the current class</code> structure and the methods involved are structured: Qt</h1> Here some of the Qt classes used: QtWidgets</a> QApplication</a> (application’s control flow)</li> QLCDNumber</a> (for the counters)</li> QSizePolicy</a></li> </ul> </li> QtGui</a> (basic imaging) QPixmap</a></li> QPainter</a></li> </ul> </li> QtCore</a> Qt</a> (e.g. Qt.Key_Escape</code> to detect ESC</code> key being pressed)</li> QSize</a> (size of a two-dimensional object)</li> </ul> </li> </ul> Writing to a File</h1> You might have noticed that the first screenshot (without the counters) showed an option at the lower left, called Select two Skat cards first</code>. The reason for that was that this version was writing a simple file to disk, which looks like this: $ head /var/tmp/skat001.txt c sl 20 12 24 27 25 31 19 16 </code></pre> The c</code> stands for the Clubs</code> variant, the sl</code> for Skat last</code>, whereas there is a sf</code> for Skat first</code> as well. The other numbers simply encode the played cards without any knowledge of the Skat rules. Where are those numbers coming from? In the past I started writing some Rust</a> code to play Skat on the console (or in the shell). It had some options to record a game, like this: $ ./target/release/skat -h Usage: ./target/release/skat [options] Options: -h, --help print this help menu -i FILE display a recorded Skat game -r, --record record a Skat game -v, --version print version number $ ./target/release/skat -r highest bid: 24 highest bid = 24 announced game [gbncshd]: c Clubs announced ... Hand? Press '1' for yes: Hand = no Are you the declarer? Press '1' for yes: 1 Declarer = yes Cards: 4: J♣ 0: A♣ 1:10♣ 2: K♣ 3: Q♣ 5: 9♣ 6: 8♣ 7: 7♣ 12: J♠ 8: A♠ 9:10♠ 10: K♠ 11: Q♠ 13: 9♠ 14: 8♠ 15: 7♠ 20: J♥ 16: A♥ 17:10♥ 18: K♥ 19: Q♥ 21: 9♥ 22: 8♥ 23: 7♥ 28: J♦ 24: A♦ 25:10♦ 26: K♦ 27: Q♦ 29: 9♦ 30: 8♦ 31: 7♦ card to play? 11 ... </code></pre> If you are the declarer you need to specify first which two cards to drop for the Skat</code>, then you play the cards for all tricks. At the end of the match you got a card distribution printed out as well as the tricks being played: ... Player A: 0: J♥ 1: J♦ 2:10♣ 3: K♣ 4: Q♣ 5: A♥ 6: A♠ 7: K♦ 8: 9♦ 9: 7♦ Player B: 0: J♣ 1: J♠ 2: A♣ 3: 9♣ 4: 8♣ 5: 7♣ 6: 8♥ 7: K♠ 8: Q♦ 9: 8♦ Player C: 0:10♥ 1: K♥ 2: Q♥ 3: 7♥ 4:10♠ 5: 9♠ 6: 8♠ 7: 7♠ 8: A♦ 9:10♦ A: J♥ J♠ A♦ B: Q♦ 10♦ 7♦ C: Q♥ A♥ 8♥ A: A♠ K♠ 9♠ A: J♦ 7♣ 7♠ A: Q♣ 8♣ 7♥ A: K♦ 8♦ 8♠ A: 9♦ 9♣ 10♠ B: J♣ 10♥ K♣ B: A♣ K♥ 10♣ New game? [press 'q' to quit] q </code></pre> All the details are not really relevant. The point is: Instead of tediously feeding the Rust program with numbers (which represent the Skat cards) you clicked all cards in an order, specifying if the first two cards (or the last ones) are representing the Skat, recorded the card order in a file (written by the Python code), and later used this option to display the card distribution and the tricks being played: $ ./target/release/skat -i /var/tmp/skat001.txt FILE = /var/tmp/skat001.txt Clubs announced ... Skat last Player A: 0: J♥ 1: J♦ 2:10♣ 3: K♣ 4: Q♣ 5: A♥ 6: A♠ 7: K♦ 8: 9♦ 9: 7♦ Player B: 0: J♣ 1: J♠ 2: A♣ 3: 9♣ 4: 8♣ 5: 7♣ 6: 8♥ 7: K♠ 8: Q♦ 9: 8♦ Player C: 0:10♥ 1: K♥ 2: Q♥ 3: 7♥ 4:10♠ 5: 9♠ 6: 8♠ 7: 7♠ 8: A♦ 9:10♦ successfully wrote to /var/tmp/skat001.dst A: J♥ J♠ A♦ B: Q♦ 10♦ 7♦ C: Q♥ A♥ 8♥ A: A♠ K♠ 9♠ A: J♦ 7♣ 7♠ A: Q♣ 8♣ 7♥ A: K♦ 8♦ 8♠ A: 9♦ 9♣ 10♠ B: J♣ 10♥ K♣ B: A♣ K♥ 10♣ Skat: Q♠ 9♥ </code></pre> This time you get the two extra cards for the Skat</code> printed as well. So, let's use Python again to show the card distribution (without the two Skat cards) and make it playable: This time the counter makes more sense, because you see one row per player: The goal for the next version of the Python code is to combine both methods (recording, and re-playing) in a single application. PBRT and Tev 2023-09-05T00:00:00+00:00 iXialumy</a> discussed (a while ago) with me how to connect rs-pbrt</a> to the image viewer tev</a> (while rendering) and made a pull request</a> about it, pretty much the same way pbrt-v4</a> does it (see video</a>). For a long time I had not much time to spend on rs_pbrt</code> and only updated the dependencies and made minor code changes. Yesterday I finally took the time to look at his solution and created a tev</code> branch on the main repository on sourcehut</a> (the github</a> and codeberg</a> repositories are more or less just mirrors with their own capability to create issues</code> and pull requests</code>). In contrast to pbrt-v4</code> the current solution renders still in buckets (which means the part of the image gets visible in tev</code> only once all samples for those pixels are calculated), whereas pbrt-v4</code> renders a full resolution noisy image first and converges to a less noisy image while more and more samples are computed: You should be able to clone</code> the repository (read-only</code>) either by: $ git clone https://git.sr.ht/~wahn/rs-pbrt Cloning into 'rs-pbrt'... ... </code></pre> Or (a read/write</code> version) by: $ git clone git@git.sr.ht:~wahn/rs-pbrt Cloning into 'rs-pbrt'... ... </code></pre> To use the tev</code> branch you must figure out that there is a remote branch of that name and then locally checkout</code> that branch. $ git branch * master $ git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/master remotes/origin/tev $ git checkout tev branch 'tev' set up to track 'origin/tev'. Switched to a new branch 'tev' $ git branch master * tev </code></pre> If you want to compile two versions (one for the tev</code> branch and one for the master</code> branch) and compile the version information into the executables you can do the following: $ git describe --tags v0.9.10-1-gccda035 $ export GIT_DESCRIBE="v0.9.10-1-gccda035" $ make ... $ mv target/ target_tev $ ./target_tev/release/rs_pbrt -h | head -n 1 rs_pbrt version 0.9.10 (v0.9.10-1-gccda035) [Detected 28 cores] </code></pre> And the same for the master</code> branch: $ git checkout master Switched to branch 'master' Your branch is up to date with 'origin/master'. $ git branch * master tev $ git describe --tags v0.9.10 $ export GIT_DESCRIBE="v0.9.10" $ make ... $ mv target/ target_master $ ./target_master/release/rs_pbrt -h | head -n 1 rs_pbrt version 0.9.10 (v0.9.10) [Detected 28 cores] </code></pre> If you pipe the output of rs_pbrt -h</code> into two text files and compare them, you will see that there is a new option now to connect to the display server (or better tev</code>): $ diff -b rs_pbrt_tev.txt rs_pbrt_master.txt 1c1 < rs_pbrt version 0.9.10 (v0.9.10-1-gccda035) [Detected 28 cores] --- > rs_pbrt version 0.9.10 (v0.9.10) [Detected 28 cores] 16d15 < --display-server <DISPLAY_SERVER> The address and port of the display server </code></pre> The full command used in the screenshot above was: $ time /media/datadisk3/git/sourcehut/rs-pbrt/target_tev/release/rs_pbrt --display-server localhost:14158 --path ganesha.pbrt ... real 1m32,956s user 35m11,823s sys 0m3,643s </code></pre> The C++</code> version of pbrt-v3</a> should be slightly faster than the Rust</code> version: $ pwd /media/datadisk3/Graphics/Rendering/PBRT/pbrt-v3-scenes/ganesha $ time /media/datadisk3/git/github/pbrt-v3/build/pbrt ganesha.pbrt pbrt version 3 (built Sep 5 2023 at 12:37:06) [Detected 28 cores] Copyright (c)1998-2018 Matt Pharr, Greg Humphreys, and Wenzel Jakob. The source code to pbrt (but *not* the book contents) is covered by the BSD License. See the file LICENSE.txt for the conditions of the license. Rendering: [+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++] (61.5s) Statistics: BVH Interior nodes 3648372 Leaf nodes 3648373 Primitives per leaf node 4323664 / 3648373 (1.19x) Integrator Camera rays traced 268378112 Path length 1.316 avg [range 0 - 4] Zero-radiance paths 146856926 / 353774467 (41.51%) Intersections Regular ray intersection tests 680824749 Shadow ray intersection tests 217814691 Ray-triangle intersection tests 435722899 / 3289961203 (13.24%) Memory BVH tree 288.65 MiB Film pixels 15.82 MiB Primitives 296.88 MiB Texture MIP maps 257.00 MiB TransformCache 260.00 kB Triangle meshes 385.41 MiB Scene AreaLights 4 Lights 5 Materials created 1 Shapes created 4323664 Probes per TransformCache lookup 1.000 avg [range 1 - 1] TransformCache hits 8 / 10 (80.00%) Triangles per triangle mesh 4323664 / 4 (1080916.00x) SpatialLightDistribution Distributions created 4212 Hash probes per lookup 1.002 avg [range 1 - 3] Lookups per distribution 353774467 / 4212 (83992.04x) Texture EWA lookups 162214764 Trilinear lookups 145501962 Profile Integrator::Render() 96.62% ( 0:01:06.63) Camera::GenerateRay[Differential]() 2.12% ( 0:00:01.46) Film::AddSample() 3.27% ( 0:00:02.25) Film::MergeTile() 0.00% ( 0:00:00.00) Sampler::GetSample[12]D() 4.88% ( 0:00:03.36) Sampler::StartPixelSample() 0.00% ( 0:00:00.00) SamplerIntegrator::Li() 84.30% ( 0:00:58.13) Accelerator::Intersect() 36.19% ( 0:00:24.96) Triangle::Intersect() 8.14% ( 0:00:05.61) BSDF::Sample_f() 3.15% ( 0:00:02.16) Direct lighting 33.99% ( 0:00:23.44) Accelerator::Intersect() 3.77% ( 0:00:02.60) Triangle::Intersect() 0.74% ( 0:00:00.51) Accelerator::IntersectP() 12.32% ( 0:00:08.49) Triangle::IntersectP() 2.36% ( 0:00:01.62) BSDF::PDF() 0.71% ( 0:00:00.48) BSDF::Sample_f() 3.31% ( 0:00:02.28) BSDF::f() 0.59% ( 0:00:00.40) Light::Pdf() 2.10% ( 0:00:01.45) Triangle::Intersect() 0.86% ( 0:00:00.59) Light::Sample_*() 2.93% ( 0:00:02.02) MIPMap::Lookup() (trilinear) 0.55% ( 0:00:00.38) MIPMap::Lookup() (trilinear) 0.26% ( 0:00:00.18) Sampler::GetSample[12]D() 3.99% ( 0:00:02.74) MIPMap::Lookup() (trilinear) 0.87% ( 0:00:00.60) Material::ComputeScatteringFunctions() 3.20% ( 0:00:02.20) MIPMap::Lookup() (EWA) 2.21% ( 0:00:01.52) Sampler::GetSample[12]D() 1.69% ( 0:00:01.16) SpatialLightDistribution lookup 0.77% ( 0:00:00.52) SpatialLightDistribution creation 0.03% ( 0:00:00.02) Light::Sample_*() 0.02% ( 0:00:00.01) MIPMap::Lookup() (trilinear) 0.01% ( 0:00:00.00) Scene parsing and creation 3.38% ( 0:00:02.33) Acceleration structure creation 1.56% ( 0:00:01.07) MIPMap::Lookup() (trilinear) 0.00% ( 0:00:00.00) Texture loading 0.77% ( 0:00:00.52) MIP map generation 0.37% ( 0:00:00.25) Profile (flattened) Accelerator::Intersect() 31.09% ( 0:00:21.43) Sampler::GetSample[12]D() 10.55% ( 0:00:07.27) Accelerator::IntersectP() 9.96% ( 0:00:06.86) Triangle::Intersect() 9.74% ( 0:00:06.71) BSDF::Sample_f() 6.45% ( 0:00:04.44) SamplerIntegrator::Li() 4.44% ( 0:00:03.06) Direct lighting 4.01% ( 0:00:02.76) Film::AddSample() 3.27% ( 0:00:02.25) Light::Sample_*() 2.39% ( 0:00:01.65) Triangle::IntersectP() 2.36% ( 0:00:01.62) MIPMap::Lookup() (EWA) 2.21% ( 0:00:01.52) Camera::GenerateRay[Differential]() 2.12% ( 0:00:01.46) Integrator::Render() 2.04% ( 0:00:01.40) MIPMap::Lookup() (trilinear) 1.70% ( 0:00:01.17) Acceleration structure creation 1.56% ( 0:00:01.07) Light::Pdf() 1.25% ( 0:00:00.85) Scene parsing and creation 1.06% ( 0:00:00.72) Material::ComputeScatteringFunctions() 0.99% ( 0:00:00.68) SpatialLightDistribution lookup 0.74% ( 0:00:00.50) BSDF::PDF() 0.71% ( 0:00:00.48) BSDF::f() 0.59% ( 0:00:00.40) Texture loading 0.40% ( 0:00:00.27) MIP map generation 0.37% ( 0:00:00.25) SpatialLightDistribution creation 0.01% ( 0:00:00.00) Film::MergeTile() 0.00% ( 0:00:00.00) Sampler::StartPixelSample() 0.00% ( 0:00:00.00) real 1m9,062s user 28m15,524s sys 0m1,292s </code></pre> Because rs_pbrt</code> renders currently to a PNG</a> file (pbrt.png</code>) and the C++ version of pbrt-v3</code> to an OpenEXR</a> file, we have to convert the image first before we can compare both images: $ /media/datadisk3/git/github/pbrt-v4/build/imgtool convert ganesha.exr --outfile ganesha_pbrt_v3.png $ imf_diff ganesha_pbrt_v3.png /media/datadisk3/git/gitlab/rs-pbrt-test-scenes/pbrt/pbrt_ganesha/pbrt.png differing pixels: 0.004% (21 of 518400) average difference: 1.674% maximum difference: 3.069% Summary: A few pixels differ slightly. == "ganesha_pbrt_v3.png" and "/media/datadisk3/git/gitlab/rs-pbrt-test-scenes/pbrt/pbrt_ganesha/pbrt.png" are similar </code></pre> There was a time where the Rust version was rendering both a PNG and an OpenEXR file, but currently this is disabled, I might bring that back one day (after I adjusted the code to the latest openexr</a> crate). Anyway, the ganesha</code> scene renders slightly different for pbrt-v4</code> (so either the material or the color correction is differently implemented). $ time /media/datadisk3/git/github/pbrt-v4/build/pbrt --display-server localhost:14158 ganesha.pbrt pbrt version 4 (built Sep 5 2023 at 12:50:51) Copyright (c)1998-2021 Matt Pharr, Wenzel Jakob, and Greg Humphreys. The source code to pbrt (but *not* the book contents) is covered by the Apache 2.0 License. See the file LICENSE.txt for the conditions of the license. Rendering: [+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++] (80.9s) real 1m26,190s user 37m28,375s sys 0m1,449s </code></pre> So the C++ version of pbrt-v4</code> is slower than the previous pbrt-v3</code> C++ version (but renders in a similar time to the Rust</code> implementation), using the CPUs</code>, but as soon as you enable the GPU</code> things get fast (depends on your graphics card): $ time /media/datadisk3/git/github/pbrt-v4/build/pbrt --display-server localhost:14158 --gpu ganesha.pbrt pbrt version 4 (built Sep 5 2023 at 12:50:51) Copyright (c)1998-2021 Matt Pharr, Wenzel Jakob, and Greg Humphreys. The source code to pbrt (but *not* the book contents) is covered by the Apache 2.0 License. See the file LICENSE.txt for the conditions of the license. Rendering: [+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++] (6.5s) real 0m9,541s user 0m11,811s sys 0m2,107s </code></pre> To compare both images (rendered on the CPU vs. the GPU) you can select both images within tev</code> and select a couple of buttons (E</code> for Error, AE</code> for Absolute Error, SE</code> for Squared Error, RAE</code> for Relative Absolute Error, and RSE</code> for Relative Squared Error): You can also compare both images via the imf_diff</code> tool: $ imf_diff -d -f ganesha_?pu.exr ganesha_diff.jpg differing pixels: 11.242% (58281 of 518400) average difference: 1.520% maximum difference: 9.705% Summary: Many pixels differ slightly. == "ganesha_cpu.exr" and "ganesha_gpu.exr" are different </code></pre> Currently the connection to tev</code> works for the Rust renderer rs_pbrt</code> only for the integrators which use the SamplerIntegrator</a> render loop. This will most likely be changed soon and before the tev</code> branch gets merged into the master</code> branch. Finally, I was interested how to watch the GPUs rendering (on Linux) and found a command line tool, called nvtop</code> (NVIDIA GPU top): Rust and Godot 4 2023-08-30T00:00:00+00:00 While looking into graphics APIs for Rust</a>, I stumbled across Teaching native graphics in 2023</a>, which made me think that OpenGL</a> is kind of dead, and maybe Vulkan</a> is not the future. Learning how to use WebGPU</a> in combination with Rust is also an option, but I started to investigate how to do this via C++ first and you can find my current state here</a>, it's based on Learn WebGPU</a> (For native graphics in C++). Currently I'm stuck</a> and therefore I looked at alternatives. So, what about using Rust within e.g. a game engine, like Godot</a>? Andrej, a friend, suggested the godot-rust</a> project. In the examples folder of gdext</a> (Godot 4 bindings) you find a project dodge-the-creeps</code> (using Rust) which is pretty similar to the Your first 2D game</a> chapter of the Godot Engine 4.1 documentation. Let's first look at the User Interface (UI) of the 2D game: It consists of two Labels</a> (score on top, message in the middle), one Button</a> (start at bottom), and a Timer</a>. The GDScript version mentioned in the Godot Engine 4.1 documentation looks like this: extends CanvasLayer # Notifies `Main` node that the button has been pressed signal start_game # Called when the node enters the scene tree for the first time. func _ready(): pass # Replace with function body. # Called every frame. 'delta' is the elapsed time since the previous frame. func _process(delta): pass func show_message(text): $Message.text = text $Message.show() $MessageTimer.start() func show_game_over(): show_message("Game Over") # Wait until the MessageTimer has counted down. await $MessageTimer.timeout $Message.text = "Dodge the\nCreeps!" $Message.show() # Make a one-shot timer and wait for it to finish. await get_tree().create_timer(1.0).timeout $StartButton.show() func update_score(score): $ScoreLabel.text = str(score) func _on_message_timer_timeout(): $Message.hide() func _on_start_button_pressed(): $StartButton.hide() start_game.emit() </code></pre> So, how does that translate to Rust? There are no classes in Rust, therefore extends CanvasLayer</code> becomes: use godot::engine::{Button, CanvasLayer, CanvasLayerVirtual, Label, Timer}; use godot::prelude::*; #[derive(GodotClass)] #[class(base=CanvasLayer)] pub struct Hud { #[base] base: Base<CanvasLayer>, } ... #[godot_api] impl CanvasLayerVirtual for Hud { fn init(base: Base<Self::Base>) -> Self { Self { base } } } </code></pre> The functions which are not empty (calling just pass</code>) translate like this to Rust: #[godot_api] impl Hud { #[signal] fn start_game(); #[func] pub fn show_message(&self, text: GodotString) { let mut message_label = self.base.get_node_as::<Label>("MessageLabel"); message_label.set_text(text); message_label.show(); let mut timer = self.base.get_node_as::<Timer>("MessageTimer"); timer.start(); } pub fn show_game_over(&self) { self.show_message("Game Over".into()); let mut message_label = self.base.get_node_as::<Label>("MessageLabel"); message_label.set_text("Dodge the\nCreeps!".into()); message_label.show(); let mut button = self.base.get_node_as::<Button>("StartButton"); button.show(); } #[func] pub fn update_score(&self, score: i64) { let mut label = self.base.get_node_as::<Label>("ScoreLabel"); label.set_text(score.to_string().into()); } #[func] fn on_start_button_pressed(&mut self) { let mut button = self.base.get_node_as::<Button>("StartButton"); button.hide(); // Note: this works only because `start_game` is a deferred signal. // This method keeps a &mut Hud, and start_game calls Main::new_game(), which itself accesses this Hud // instance through Gd<Hud>::bind_mut(). It will try creating a 2nd &mut reference, and thus panic. // Deferring the signal is one option to work around it. self.base.emit_signal("start_game".into(), &[]); } #[func] fn on_message_timer_timeout(&self) { let mut message_label = self.base.get_node_as::<Label>("MessageLabel"); message_label.hide() } } </code></pre> The GDScript version of Main</code> defines a variable score</code> and exports a PackedScene</code> with the name mob_scene</code>: extends Node @export var mob_scene: PackedScene var score # Called when the node enters the scene tree for the first time. func _ready(): pass # Called every frame. 'delta' is the elapsed time since the previous frame. func _process(delta): pass func game_over(): $ScoreTimer.stop() $MobTimer.stop() $HUD.show_game_over() $Music.stop() $DeathSound.play() func new_game(): score = 0 $Player.start($StartPosition.position) $StartTimer.start() $HUD.update_score(score) $HUD.show_message("Get Ready") get_tree().call_group("mobs", "queue_free") $Music.play() func _on_mob_timer_timeout(): # Create a new instance of the Mob scene. var mob = mob_scene.instantiate() # Choose a random location on Path2D. var mob_spawn_location = get_node("MobPath/MobSpawnLocation") mob_spawn_location.progress_ratio = randf() # Set the mob's direction perpendicular to the path direction. var direction = mob_spawn_location.rotation + PI / 2 # Set the mob's position to a random location. mob.position = mob_spawn_location.position # Add some randomness to the direction. direction += randf_range(-PI / 4, PI / 4) mob.rotation = direction # Choose the velocity for the mob. var velocity = Vector2(randf_range(150.0, 250.0), 0.0) mob.linear_velocity = velocity.rotated(direction) # Spawn the mob by adding it to the Main scene. add_child(mob) func _on_score_timer_timeout(): score += 1 $HUD.update_score(score) func _on_start_timer_timeout(): $MobTimer.start() $ScoreTimer.start() </code></pre> It's interesting how score</code> gets translated to a Rust member of the struct Main</code>, and in addition to mob_scene</code> there are two optional pointers to the two instances of AudioStreamPlayer</code>, music</code> and death_sound</code>: use crate::hud::Hud; use crate::mob; use crate::player; use godot::engine::{Marker2D, PathFollow2D, RigidBody2D, Timer}; use godot::prelude::*; use rand::Rng as _; use std::f32::consts::PI; // Deriving GodotClass makes the class available to Godot #[derive(GodotClass)] #[class(base=Node)] pub struct Main { mob_scene: Gd<PackedScene>, music: Option<Gd<AudioStreamPlayer>>, death_sound: Option<Gd<AudioStreamPlayer>>, score: i64, #[base] base: Base<Node>, } #[godot_api] impl Main { #[func] fn game_over(&mut self) { let mut score_timer = self.base.get_node_as::<Timer>("ScoreTimer"); let mut mob_timer = self.base.get_node_as::<Timer>("MobTimer"); score_timer.stop(); mob_timer.stop(); let mut hud = self.base.get_node_as::<Hud>("Hud"); hud.bind_mut().show_game_over(); self.music().stop(); self.death_sound().play(); } #[func] pub fn new_game(&mut self) { let start_position = self.base.get_node_as::<Marker2D>("StartPosition"); let mut player = self.base.get_node_as::<player::Player>("Player"); let mut start_timer = self.base.get_node_as::<Timer>("StartTimer"); self.score = 0; player.bind_mut().start(start_position.get_position()); start_timer.start(); let mut hud = self.base.get_node_as::<Hud>("Hud"); let hud = hud.bind_mut(); hud.update_score(self.score); hud.show_message("Get Ready".into()); self.music().play(); } #[func] fn on_start_timer_timeout(&self) { let mut mob_timer = self.base.get_node_as::<Timer>("MobTimer"); let mut score_timer = self.base.get_node_as::<Timer>("ScoreTimer"); mob_timer.start(); score_timer.start(); } #[func] fn on_score_timer_timeout(&mut self) { self.score += 1; let mut hud = self.base.get_node_as::<Hud>("Hud"); hud.bind_mut().update_score(self.score); } #[func] fn on_mob_timer_timeout(&mut self) { let mut mob_spawn_location = self .base .get_node_as::<PathFollow2D>("MobPath/MobSpawnLocation"); let mut mob_scene = self.mob_scene.instantiate_as::<RigidBody2D>(); let mut rng = rand::thread_rng(); let progress = rng.gen_range(u32::MIN..u32::MAX); mob_spawn_location.set_progress(progress as f32); mob_scene.set_position(mob_spawn_location.get_position()); let mut direction = mob_spawn_location.get_rotation() + PI / 2.0; direction += rng.gen_range(-PI / 4.0..PI / 4.0); mob_scene.set_rotation(direction); self.base.add_child(mob_scene.share().upcast()); let mut mob = mob_scene.cast::<mob::Mob>(); let range = { // Local scope to bind `mob` user object let mob = mob.bind(); rng.gen_range(mob.min_speed..mob.max_speed) }; mob.set_linear_velocity(Vector2::new(range, 0.0)); let lin_vel = mob.get_linear_velocity().rotated(real::from_f32(direction)); mob.set_linear_velocity(lin_vel); let mut hud = self.base.get_node_as::<Hud>("Hud"); hud.connect( "start_game".into(), Callable::from_object_method(mob, "on_start_game"), ); } fn music(&mut self) -> &mut AudioStreamPlayer { self.music.as_deref_mut().unwrap() } fn death_sound(&mut self) -> &mut AudioStreamPlayer { self.death_sound.as_deref_mut().unwrap() } } #[godot_api] impl NodeVirtual for Main { fn init(base: Base<Node>) -> Self { Main { mob_scene: PackedScene::new(), score: 0, base, music: None, death_sound: None, } } fn ready(&mut self) { // Note: this is downcast during load() -- completely type-safe thanks to type inference! // If the resource does not exist or has an incompatible type, this panics. // There is also try_load() if you want to check whether loading succeeded. self.mob_scene = load("res://Mob.tscn"); self.music = Some(self.base.get_node_as("Music")); self.death_sound = Some(self.base.get_node_as("DeathSound")); } } </code></pre> The GDScript can just access $Music</code> and $DeathSound</code> to play or stop playing the music. The Rust version seems to gain access at the right time, during the call of Main::ready</code>, even though the GDScript equivalent just calls pass</code>. Later we need a &mut</code> (mutable reference) to AudioStreamPlayer</code> to call play()</code> or stop()</code>, and therefore the Main</code> struct provides functions music()</code> and death_sound()</code> to provide such a reference. Here the GDScript version for Player</code>: extends Area2D signal hit @export var speed = 400 # How fast the player will move (pixels/sec). var screen_size # Size of the game window. # Called when the node enters the scene tree for the first time. func _ready(): screen_size = get_viewport_rect().size hide() # Called every frame. 'delta' is the elapsed time since the previous frame. func _process(delta): var velocity = Vector2.ZERO # The player's movement vector. if Input.is_action_pressed("move_right"): velocity.x += 1 if Input.is_action_pressed("move_left"): velocity.x -= 1 if Input.is_action_pressed("move_down"): velocity.y += 1 if Input.is_action_pressed("move_up"): velocity.y -= 1 if velocity.length() > 0: velocity = velocity.normalized() * speed $AnimatedSprite2D.play() else: $AnimatedSprite2D.stop() position += velocity * delta position = position.clamp(Vector2.ZERO, screen_size) if velocity.x != 0: $AnimatedSprite2D.animation = "walk" $AnimatedSprite2D.flip_v = false # See the note below about boolean assignment. $AnimatedSprite2D.flip_h = velocity.x < 0 elif velocity.y != 0: $AnimatedSprite2D.animation = "up" $AnimatedSprite2D.flip_v = velocity.y > 0 func _on_body_entered(body): hide() # Player disappears after being hit. hit.emit() # Must be deferred as we can't change physics properties on a physics callback. $CollisionShape2D.set_deferred("disabled", true) func start(pos): position = pos show() $CollisionShape2D.disabled = false </code></pre> Verse the Rust version: use godot::engine::{AnimatedSprite2D, Area2D, Area2DVirtual, CollisionShape2D, PhysicsBody2D}; use godot::prelude::*; #[derive(GodotClass)] #[class(base=Area2D)] pub struct Player { speed: real, screen_size: Vector2, #[base] base: Base<Area2D>, } #[godot_api] impl Player { #[signal] fn hit(); #[func] fn on_player_body_entered(&mut self, _body: Gd<PhysicsBody2D>) { self.base.hide(); self.base.emit_signal("hit".into(), &[]); let mut collision_shape = self .base .get_node_as::<CollisionShape2D>("CollisionShape2D"); collision_shape.set_deferred("disabled".into(), true.to_variant()); } #[func] pub fn start(&mut self, pos: Vector2) { self.base.set_global_position(pos); self.base.show(); let mut collision_shape = self .base .get_node_as::<CollisionShape2D>("CollisionShape2D"); collision_shape.set_disabled(false); } } #[godot_api] impl Area2DVirtual for Player { fn init(base: Base<Area2D>) -> Self { Player { speed: 400.0, screen_size: Vector2::new(0.0, 0.0), base, } } fn ready(&mut self) { let viewport = self.base.get_viewport_rect(); self.screen_size = viewport.size; self.base.hide(); } fn process(&mut self, delta: f64) { let mut animated_sprite = self .base .get_node_as::<AnimatedSprite2D>("AnimatedSprite2D"); let mut velocity = Vector2::new(0.0, 0.0); // Note: exact=false by default, in Rust we have to provide it explicitly let input = Input::singleton(); if input.is_action_pressed("move_right".into()) { velocity += Vector2::RIGHT; } if input.is_action_pressed("move_left".into()) { velocity += Vector2::LEFT; } if input.is_action_pressed("move_down".into()) { velocity += Vector2::DOWN; } if input.is_action_pressed("move_up".into()) { velocity += Vector2::UP; } if velocity.length() > 0.0 { velocity = velocity.normalized() * self.speed; let animation; if velocity.x != 0.0 { animation = "right"; animated_sprite.set_flip_v(false); animated_sprite.set_flip_h(velocity.x < 0.0) } else { animation = "up"; animated_sprite.set_flip_v(velocity.y > 0.0) } animated_sprite.play_ex().name(animation.into()).done(); } else { animated_sprite.stop(); } let change = velocity * real::from_f64(delta); let position = self.base.get_global_position() + change; let position = Vector2::new( position.x.clamp(0.0, self.screen_size.x), position.y.clamp(0.0, self.screen_size.y), ); self.base.set_global_position(position); } } </code></pre> One thing worth mentioning here is that I noticed a mismatch between the two Godot 4 scenes (one using GDScript, the other one Rust): This explains why the GDScript version uses up</code> and walk</code> whereas the Rust version uses up</code> and right</code>. Language Server Protocol - Helix and Emacs 2023-08-12T00:00:00+00:00 I wrote already about the Language Server Protocol and Text Editors</a> a while ago, but this time I would like to focus on a larger code base and how to use your text editor to navigate through the source code after compilation. As an example I compiled pbrt-v4</a> on my MacBook Pro and used the CMAKE_EXPORT_COMPILE_COMMANDS</code> option of CMake</a> to create a compile_commands.json</code> file (see CMake Tutorial</a>): % cd ~/git/github/pbrt-v4 % mkdir build % cd build % cmake .. -DCMAKE_EXPORT_COMPILE_COMMANDS=1 % cmake --build . ... % head compile_commands.json [ { "directory": "/Users/jan/git/github/pbrt-v4/build", "command": "/Library/Developer/CommandLineTools/usr/bin/c++ -DPBRT_HAVE_MMAP ... -std=gnu++17 ...", "file": "/Users/jan/git/github/pbrt-v4/src/pbrt/cmd/soac.cpp", "output": "CMakeFiles/soac.dir/src/pbrt/cmd/soac.cpp.o" }, ... </code></pre> The resulting compile_commands.json</code> file contains basically for each C++ file a description how the file was compiled, including the full path to the compiler and all compiler options and defines. Helix</h2> So let's try to find an interesting C++ file to start with and use the Helix</a> editor to view it: % ./pbrt pbrt version 4 (built Aug 12 2023 at 09:56:20) Copyright (c)1998-2021 Matt Pharr, Wenzel Jakob, and Greg Humphreys. The source code to pbrt (but *not* the book contents) is covered by the Apache 2.0 License. See the file LICENSE.txt for the conditions of the license. ^C % rg "pbrt version 4" .. ../src/pbrt/cmd/pbrt.cpp 217: printf("pbrt version 4 (built %s at %s)\n", __DATE__, __TIME__); % hx ../src/pbrt/cmd/pbrt.cpp </code></pre> The syntax highlighting works already, but on my computer the path to the language server</code> is not found by default: % hx --health cpp Configured language server: clangd Binary for language server: 'clangd' not found in $PATH Configured debug adapter: lldb-vscode Binary for debug adapter: 'lldb-vscode' not found in $PATH Highlight queries: ✓ Textobject queries: ✓ Indent queries: ✓ </code></pre> Let's fix that: % set | grep "^PATH" PATH='...:/usr/local/bin:...' % locate clangd | head -n 1 /Library/Developer/CommandLineTools/usr/bin/clangd % export PATH=/Library/Developer/CommandLineTools/usr/bin:$PATH % hx --health cpp Configured language server: clangd Binary for language server: /Library/Developer/CommandLineTools/usr/bin/clangd Configured debug adapter: lldb-vscode Binary for debug adapter: 'lldb-vscode' not found in $PATH Highlight queries: ✓ Textobject queries: ✓ Indent queries: ✓ </code></pre> Now we are looking for some warnings during compilation: % cmake --build . ... /Users/jan/git/github/pbrt-v4/src/ext/ptex/src/ptex/PtexCache.h:289:21: warning: ... ... /Users/jan/git/github/pbrt-v4/src/ext/ptex/src/ptex/PtexUtils.cpp:51:22: warning: ... % hx /Users/jan/git/github/pbrt-v4/src/ext/ptex/src/ptex/PtexCache.h </code></pre> After loading the header file in question (which created the first warning) you can see an orange dot in the lower right part: You can jump to that line by pressing ]</code> followed by d</code>. The warning message which was shown during compilation is now visible in orange in the upper right corner. The second file mentioned above (PtexUtils.cpp</code>) has 4 warnings in it. Try to load the file into Helix and navigate to the lines responsible for those warnings. Emacs</h2> Alternatively you can load one of the files into Emacs</a> and use one of the packages provided there: % emacs -nw /Users/jan/git/github/pbrt-v4/src/ext/ptex/src/ptex/PtexUtils.cpp </code></pre> After loading the file you can replace the default cc-mode</code> and activate syntax highlighting using Tree-sitter</a> via M-x tree-sitter-hl-mode</code> (for older Emacs versions you might have to install the Emacs binding</a> first). For using the language server you can use e.g. the Emacs LSP client Emacs Polyglot</a> via M-x eglot</code> and navigate via M-x flymake-goto-next-error</code> to the next warning message. Or you use M-x flymake-show-buffer-diagnostics</code> to see all warnings in an extra buffer where you can select the warning line and jump directly to C++ line which caused it (see above). Others</h2> The Language Server Protocol</a> (LSP) can be used with many other text editors or IDEs. I just wanted to mention two of my favourite text editors, Emacs</code> which is around for ages, and Helix</code>, which is pretty new, written in Rust</a>, and looks pretty promising (regarding LSP and Tree-sitter). PBRT v4 - Part III: Watercolor Scene - denoised 2023-07-18T00:00:00+00:00 The last part (PBRT v4 - Part II: OptiX denoiser</a>) introduced the OptiX denoiser. Let's apply this to another scene, the Watercolor Scene. The scene comes with 18 camera perspectives, so there is a lot of material to play with, but I have selected only two of them for this blog post. I did render both camera perspectives (camera-9</code> and camera-13</code>) with 4096 samples per pixel (spp</code>), copied the results into a subfolder (spp4096</code>), and applied the OptiX denoiser there. $ pbrt --stats --spp 4096 camera-9.pbrt ... $ pbrt --stats --spp 4096 camera-13.pbrt ... $ cp camera-9.exr spp4096/camera-9-4096spp.exr $ cp camera-13.exr spp4096/camera-13-4096spp.exr $ cd spp4096/ $ imgtool convert camera-9-4096spp.exr --outfile camera-9-4096spp.png $ imgtool convert camera-13-4096spp.exr --outfile camera-13-4096spp.png $ imgtool denoise-optix camera-9-4096spp.exr --outfile camera-9-denoised-4096spp.png $ imgtool denoise-optix camera-13-4096spp.exr --outfile camera-13-denoised-4096spp.png </code></pre> For convenience I provide a watercolor_spp4096.zip</a> file with the OpenEXR and PNG files involved: $ unzip -l watercolor_spp4096.zip Archive: watercolor_spp4096.zip Length Date Time Name --------- ---------- ----- ---- 0 07-18-2023 06:28 spp4096/ 1003526 07-18-2023 06:23 spp4096/camera-13-denoised-4096spp.png 1338772 07-18-2023 06:28 spp4096/camera-13-4096spp.png 764671 07-18-2023 06:23 spp4096/camera-9-denoised-4096spp.png 1106958 07-18-2023 06:28 spp4096/camera-9-4096spp.png 18447347 07-18-2023 06:19 spp4096/camera-13-4096spp.exr 17286470 07-18-2023 06:19 spp4096/camera-9-4096spp.exr --------- ------- 39947744 7 files </code></pre> It's best to download those files and compare them yourself using your favourite image viewer. Camera 13</h2> The biggest visual difference between the denoised version and the original rendering for camera 13</code> are the two glasses (one filled with colored water) and the floor pattern: $ imf_diff -d -f camera-13-4096spp.png camera-13-denoised-4096spp.png diff-002.jpg differing pixels: 28.785% (215885 of 750000) average difference: 1.823% maximum difference: 13.865% Summary: Many pixels differ. == "camera-13-4096spp.png" and "camera-13-denoised-4096spp.png" are different </code></pre> Camera 9</h2> For camera 9 the difference is really hard to catch by eye. If you can spot them it's most visible in the specular highlights of the cans (and the wavy parts). But the shadows on the white walls are noticeable less noisy. $ imf_diff -d -f camera-9-4096spp.png camera-9-denoised-4096spp.png diff-001.jpg differing pixels: 10.669% (80020 of 750000) average difference: 1.169% maximum difference: 6.207% Summary: Many pixels differ slightly. == "camera-9-4096spp.png" and "camera-9-denoised-4096spp.png" are different </code></pre> PBRT v4 - Part II: OptiX denoiser 2023-07-17T00:00:00+00:00 The last part (PBRT v4 - Part I: Kroken Scene</a>) briefly talked about the imgtool</code>. The README.md</a> file mentions the support for the OptiX denoiser: The imgtool program that is built as part of pbrt provides support for the OptiX denoiser in the GPU build. The denoiser is capable of operating on RGB-only images, but gives better results with "deep" images that include auxiliary channels like albedo and normal. </blockquote> CUDA</h2> I ran into some problems regarding the CUDA installation and followed a NVIDIA Rtx 2080 Ti Ubuntu 20.04 Driver Installation</a> instruction, which is more specific to my graphics card and Linux distribution. As root: # apt install aptitude # aptitude install nvidia-driver-535 nvidia-settings # apt-get dist-upgrade </code></pre> It's not related to the next steps, but I decided to also upgrade from Ubuntu 20.04 LTS to 22.04 LTS</a>: # uname -mrs Linux 5.15.0-76-generic x86_64 # lsb_release -a LSB Version: core-11.1.0ubuntu4-noarch:security-11.1.0ubuntu4-noarch Distributor ID: Ubuntu Description: Ubuntu 22.04.2 LTS Release: 22.04 Codename: jammy </code></pre> OptiX</h2> Beside CUDA we need OptiX</a> installed. # cd ~jan/Downloads/ # sh NVIDIA-OptiX-SDK-7.7.0-linux64-x86_64.sh ... # cd NVIDIA-OptiX-SDK-7.7.0-linux64-x86_64 # pwd /home/jan/Downloads/NVIDIA-OptiX-SDK-7.7.0-linux64-x86_64 # ls -1 doc include SDK # chown -R jan:jan . </code></pre> I did run the commands above as root, which I compensated for by chown</code>. I guess running it as user would have made more sense. Compiling</h2> I did install CUDA</a> following the guide</a> but that is not enough: $ cmake --version cmake version 3.26.4 CMake suite maintained and supported by Kitware (kitware.com/cmake). $ pwd /media/datadisk3/git/github/pbrt-v4 $ mkdir build $ cd build/ $ cmake .. ... -- Found CUDA: /usr/local/cuda (found version "12.2") -- Found CUDA: 12.2.91 CMake Warning at CMakeLists.txt:189 (message): Found CUDA but PBRT_OPTIX7_PATH is not set. Disabling GPU compilation. ... </code></pre> It can find CUDA, but we need to set the PBRT_OPTIX7_PATH</code>. Let's try again (after installing OptiX): $ export PBRT_OPTIX7_PATH=/home/jan/Downloads/NVIDIA-OptiX-SDK-7.7.0-linux64-x86_64 $ cd/media/datadisk3/git/github/pbrt-v4 $ rm -rf build/ $ mkdir build $ cd build/ $ cmake .. -- The CXX compiler identification is GNU 11.3.0 -- The C compiler identification is GNU 11.3.0 -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Setting build type to 'Release' as none was specified. -- Found Git: /home/linuxbrew/.linuxbrew/bin/git (found version "2.41.0") -- OpenEXR at commit: 5cfb5dab6dfada731586b0281bdb15ee75e26782 -- OpenVDB at commit: 414bed84c2fc22e188eac7b611aa85c7edd7a5a9 -- Ptex at commit: 4cd8e9a6db2b06e478dfbbd8c26eb6df97f84483 -- double-conversion at commit: cc1f75a114aca8d2af69f73a5a959aecbab0e87a -- filesystem at commit: c5f9de30142453eb3c6fe991e82dfc2583373116 -- glfw at commit: 4cb36872a5fe448c205d0b46f0e8c8b57530cfe0 -- libdeflate at commit: 1fd0bea6ca2073c68493632dafc4b1ddda1bcbc3 -- lodepng at commit: 8c6a9e30576f07bf470ad6f09458a2dcd7a6a84a -- qoi at commit: 028c75fd26e5e0758c7c711216c00404994c1ad3 -- stb at commit: af1a5bc352164740c1cc1354942b1c6b72eacb8a -- utf8proc at commit: 2484e2ed5e1d9c19edcccf392a7d9920ad90dfaf -- zlib at commit: 54d591eabf9fe0e84c725638f8d5d8d202a093fa -- Performing Test CMAKE_HAVE_LIBC_PTHREAD -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success -- Found Threads: TRUE -- Found OpenGL: /usr/lib/x86_64-linux-gnu/libOpenGL.so -- The ASM compiler identification is GNU -- Found assembler: /usr/bin/cc CMake Warning (dev) at src/ext/libdeflate/CMakeLists.txt:12 (option): Policy CMP0077 is not set: option() honors normal variables. Run "cmake --help-policy CMP0077" for policy details. Use the cmake_policy command to set the policy and suppress this warning. For compatibility with older versions of CMake, option is clearing the normal variable 'BUILD_SHARED_LIBS'. This warning is for project developers. Use -Wno-dev to suppress it. -- Performing Test DEFLATE_LINT_WALL -- Performing Test DEFLATE_LINT_WALL - Success -- Performing Test DEFLATE_LINT_WUNDEF -- Performing Test DEFLATE_LINT_WUNDEF - Success -- Performing Test DEFLATE_LINT_PEDANTIC -- Performing Test DEFLATE_LINT_PEDANTIC - Success -- Performing Test DEFLATE_LINT_DECLARATION_AFTER_STATEMENT -- Performing Test DEFLATE_LINT_DECLARATION_AFTER_STATEMENT - Success -- Performing Test DEFLATE_LINT_MISSING_PROTOTYPES -- Performing Test DEFLATE_LINT_MISSING_PROTOTYPES - Success -- Performing Test DEFLATE_LINT_STRICT_PROTOTYPES -- Performing Test DEFLATE_LINT_STRICT_PROTOTYPES - Success -- Performing Test DEFLATE_LINT_VLA -- Performing Test DEFLATE_LINT_VLA - Success -- Performing Test DEFLATE_LINT_IMPLICIT_FALLTHROUGH -- Performing Test DEFLATE_LINT_IMPLICIT_FALLTHROUGH - Success -- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.11") -- Could NOT find Imath (missing: Imath_DIR) -- Found PkgConfig: /home/linuxbrew/.linuxbrew/bin/pkg-config (found version "0.29.2") -- Found OpenEXR: /usr/include (found suitable version "2.5.7", minimum required is "2.3") -- Found OpenEXR version 2.5.7 CMake Deprecation Warning at src/ext/ptex/CMakeLists.txt:1 (cmake_minimum_required): Compatibility with CMake < 2.8.12 will be removed from a future version of CMake. Update the VERSION argument <min> value or use a ...<max> suffix to tell CMake that the project does not need compatibility with older versions. -- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE) -- Including X11 support -- Found X11: /usr/include -- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so -- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so - found -- Looking for gethostbyname -- Looking for gethostbyname - found -- Looking for connect -- Looking for connect - found -- Looking for remove -- Looking for remove - found -- Looking for shmat -- Looking for shmat - found -- Looking for IceConnectionNumber in ICE -- Looking for IceConnectionNumber in ICE - found -- Unable to find -lprofiler -- Looking for a CUDA compiler -- Looking for a CUDA compiler - /usr/local/cuda/bin/nvcc -- Found CUDA: /usr/local/cuda (found version "12.2") -- Found CUDA: 12.2.91 -- The CUDA compiler identification is NVIDIA 12.2.91 -- Detecting CUDA compiler ABI info -- Detecting CUDA compiler ABI info - done -- Check for working CUDA compiler: /usr/local/cuda/bin/nvcc - skipped -- Detecting CUDA compile features -- Detecting CUDA compile features - done -- Detected CUDA Architecture: sm_75 -- Performing Test COMPILER_SUPPORTS_MARCH_NATIVE -- Performing Test COMPILER_SUPPORTS_MARCH_NATIVE - Success -- Performing Test HAVE_MMAP -- Performing Test HAVE_MMAP - Success -- Performing Test HAS_INTRIN_H -- Performing Test HAS_INTRIN_H - Failed -- Performing Test HAVE_DECLSPEC_NOINLINE -- Performing Test HAVE_DECLSPEC_NOINLINE - Failed -- Performing Test HAVE_ATTRIBUTE_NOINLINE -- Performing Test HAVE_ATTRIBUTE_NOINLINE - Success -- Performing Test HAVE_PRE_POST_BAR_RESTRICT -- Performing Test HAVE_PRE_POST_BAR_RESTRICT - Success -- Performing Test HAVE_PRE_BAR_RESTRICT -- Performing Test HAVE_PRE_BAR_RESTRICT - Success -- Performing Test HAVE__ALIGNED_MALLOC -- Performing Test HAVE__ALIGNED_MALLOC - Failed -- Performing Test HAVE_POSIX_MEMALIGN -- Performing Test HAVE_POSIX_MEMALIGN - Success -- Performing Test INT64_IS_OWN_TYPE -- Performing Test INT64_IS_OWN_TYPE - Failed -- Configuring done (11.4s) CMake Warning (dev) in CMakeLists.txt: Policy CMP0104 is not set: CMAKE_CUDA_ARCHITECTURES now detected for NVCC, empty CUDA_ARCHITECTURES not allowed. Run "cmake --help-policy CMP0104" for policy details. Use the cmake_policy command to set the policy and suppress this warning. CUDA_ARCHITECTURES is empty for target "optix.cu". This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) in CMakeLists.txt: Policy CMP0104 is not set: CMAKE_CUDA_ARCHITECTURES now detected for NVCC, empty CUDA_ARCHITECTURES not allowed. Run "cmake --help-policy CMP0104" for policy details. Use the cmake_policy command to set the policy and suppress this warning. CUDA_ARCHITECTURES is empty for target "pbrt_lib". This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) in CMakeLists.txt: Policy CMP0104 is not set: CMAKE_CUDA_ARCHITECTURES now detected for NVCC, empty CUDA_ARCHITECTURES not allowed. Run "cmake --help-policy CMP0104" for policy details. Use the cmake_policy command to set the policy and suppress this warning. CUDA_ARCHITECTURES is empty for target "pbrt_lib". This warning is for project developers. Use -Wno-dev to suppress it. -- Generating done (0.1s) -- Build files have been written to: /media/datadisk3/git/github/pbrt-v4/build $ cmake --build . ... </code></pre> imgtool</h2> After a successful compilation there should be an command</code> for denoising: $ ./imgtool --help |& grep denoise -A 2 denoise-optix: Denoises the image using NVIDIA's OptiX denoiser which is based on a deep neural network. The provided image should be a multi-channel EXR as generated by pbrt's "gbuffer" film. </code></pre> Denoising</h2> So, after rendering the camera-1</code> with only a few samples per pixel (--spp 16</code>): # time /media/datadisk3/git/github/pbrt-v4/build/pbrt --stats --spp 16 --display-server localhost:14158 camera-1.pbrt pbrt version 4 (built Jul 17 2023 at 10:07:34) Copyright (c)1998-2021 Matt Pharr, Wenzel Jakob, and Greg Humphreys. The source code to pbrt (but *not* the book contents) is covered by the Apache 2.0 License. See the file LICENSE.txt for the conditions of the license. Warning: lights.pbrt:7:4: Converting non-RGB "L" parameter to RGB so that a portal light can be used. Rendering: [+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++] (15.4s) Statistics: BVH Interior nodes 287361520 Leaf nodes 287361531 Nodes visited 6629373242 Primitives per leaf node 287902422 / 287361531 (1.00x) Geometry Spheres 2 Triangles added from displacement mapping 247702869 Buffer cache hits 239 / 955 (25.03%) Triangles per mesh 287904585 / 248 (1160905.58x) Integrator Camera rays traced 9000000 Surface interactions 34527288 Volume interactions 80435 Intersections Regular ray intersection tests 60905400 Ray-Triangle intersection tests 73770948 / 338834471 (0.22x) Memory BVH 19.27 GiB Film pixels 103.00 MiB Image maps 159.38 MiB Light BVH 184.91 kB Primitives 4.29 GiB Redundant vertex and index buffers 347.69 MiB Tokenizer buffers 244.50 kB Triangles 2.15 GiB Unreported / unused 20.18 GiB Scene AreaLights 2175 Lights 2176 Materials 80 Object instances created 10 Textures 164 real 2m22,187s user 37m21,370s sys 1m4,984s </code></pre> I get an image, which looks good for trying the OptiX denoiser: In the lower part you see the 10 available AOVs, or according to the README.md file: The denoiser is capable of operating on RGB-only images, but gives better results with "deep" images that include auxiliary channels like albedo and normal. Setting the scene's "Film" type to be "gbuffer" when rendering and using EXR for the image format causes pbrt to generate such a "deep" image. In either case, using the denoiser is straightforward: </blockquote> $ imgtool denoise-optix noisy.exr --outfile denoised.exr </code></pre> There was a bug</a> which made the imgtool</code> crash: $ /media/datadisk3/git/github/pbrt-v4/build/imgtool denoise-optix camera-1.exr --outfile camera-1-denoised.exr [ tid 38281 @ 0.000s cmd/imgtool.cpp:2285 ] FATAL Check failed: desc (/media/datadisk3/git/github/pbrt-v4/build/imgtool) 0x0x555f0f3df77a - pbrt::PrintStackTrace() + 0x3a (/media/datadisk3/git/github/pbrt-v4/build/imgtool) 0x0x555f0f3dfa11 - pbrt::CheckCallbackScope::Fail() + 0x21 (/media/datadisk3/git/github/pbrt-v4/build/imgtool) 0x0x555f0f450692 - pbrt::LogFatal(pbrt::LogLevel, char const*, int, char const*) + 0xf2 (/media/datadisk3/git/github/pbrt-v4/build/imgtool) 0x0x555f0f23385c - void pbrt::LogFatal<char const (&) [5]>(pbrt::LogLevel, char const*, int, char const*, char const (&) [5]) + 0x5c (/media/datadisk3/git/github/pbrt-v4/build/imgtool) 0x0x555f0f210810 - denoise_optix(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >) + 0x16a0 (/media/datadisk3/git/github/pbrt-v4/build/imgtool) 0x0x555f0f1f1b74 - main + 0x4a4 (/lib/x86_64-linux-gnu/libc.so.6 ) 0x0x7fba5476fd90 - (unknown) + 0x29d90 (/lib/x86_64-linux-gnu/libc.so.6 ) 0x0x7fba5476fe40 - __libc_start_main + 0x80 (/media/datadisk3/git/github/pbrt-v4/build/imgtool) 0x0x555f0f1f8845 - _start + 0x25 </code></pre> But that bug is fixed now: $ /media/datadisk3/git/github/pbrt-v4/build/imgtool denoise-optix camera-1.exr --outfile camera-1-denoised.exr </code></pre> So, the denoised image looks like this: To get a better denoised image you have to go up with the samples per pixel (spp</code>). Just to give you an impression about the render times involved here some timings. 512 spp</h3> $ time /media/datadisk3/git/github/pbrt-v4/build/pbrt --stats --spp 512 --display-server localhost:14158 camera-1.pbrt pbrt version 4 (built Jul 17 2023 at 10:07:34) Copyright (c)1998-2021 Matt Pharr, Wenzel Jakob, and Greg Humphreys. The source code to pbrt (but *not* the book contents) is covered by the Apache 2.0 License. See the file LICENSE.txt for the conditions of the license. Warning: lights.pbrt:7:4: Converting non-RGB "L" parameter to RGB so that a portal light can be used. Rendering: [+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++] (484.4s) Statistics: BVH Interior nodes 287361520 Leaf nodes 287361531 Nodes visited 212010387147 Primitives per leaf node 287902422 / 287361531 (1.00x) Geometry Spheres 2 Triangles added from displacement mapping 247702869 Buffer cache hits 239 / 955 (25.03%) Triangles per mesh 287904585 / 248 (1160905.58x) Integrator Camera rays traced 288000000 Surface interactions 1105085147 Volume interactions 2583979 Intersections Regular ray intersection tests 1946897492 Ray-Triangle intersection tests 2358479334 / 10860335472 (0.22x) Memory BVH 19.27 GiB Film pixels 103.00 MiB Image maps 159.38 MiB Light BVH 184.91 kB Primitives 4.29 GiB Redundant vertex and index buffers 347.69 MiB Tokenizer buffers 244.50 kB Triangles 2.15 GiB Unreported / unused 17.34 GiB Scene AreaLights 2175 Lights 2176 Materials 80 Object instances created 10 Textures 164 real 9m40,461s user 251m16,214s sys 1m20,055s </code></pre> 4096 spp</h3> $ time /media/datadisk3/git/github/pbrt-v4/build/pbrt --stats --spp 4096 --display-server localhost:14158 camera-1.pbrt pbrt version 4 (built Jul 17 2023 at 10:07:34) Copyright (c)1998-2021 Matt Pharr, Wenzel Jakob, and Greg Humphreys. The source code to pbrt (but *not* the book contents) is covered by the Apache 2.0 License. See the file LICENSE.txt for the conditions of the license. Warning: lights.pbrt:7:4: Converting non-RGB "L" parameter to RGB so that a portal light can be used. Rendering: [+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++] (3905.8s) Statistics: BVH Interior nodes 287361520 Leaf nodes 287361531 Nodes visited 1696150927268 Primitives per leaf node 287902422 / 287361531 (1.00x) Geometry Spheres 2 Triangles added from displacement mapping 247702869 Buffer cache hits 239 / 955 (25.03%) Triangles per mesh 287904585 / 248 (1160905.58x) Integrator Camera rays traced 2304000000 Surface interactions 8840927010 Volume interactions 20661349 Intersections Regular ray intersection tests 15575563124 Ray-Triangle intersection tests 18868365257 / 86881430559 (0.22x) Memory BVH 19.27 GiB Film pixels 103.00 MiB Image maps 159.38 MiB Light BVH 184.91 kB Primitives 4.29 GiB Redundant vertex and index buffers 347.69 MiB Tokenizer buffers 244.50 kB Triangles 2.15 GiB Unreported / unused 16.88 GiB Scene AreaLights 2175 Lights 2176 Materials 80 Object instances created 10 Textures 164 real 66m40,878s user 1799m14,847s sys 1m34,903s </code></pre> This is pretty much the same image we rendered the last time using --spp 4096</code> (samples per pixel), but this time we denoise it during the conversion from OpenEXR to PNG: $ cp camera-1.exr camera-1-4096spp.exr $ /media/datadisk3/git/github/pbrt-v4/build/imgtool denoise-optix camera-1-4096spp.exr --outfile camera-1-4096spp.png Warning: camera-1-4096spp.png: 75309 out of gamut pixel channels clamped to [0,1]. </code></pre> The difference is a bit hard to catch by eye, but the imf_diff</code> tool helps to see it, using false-color</code>: $ imf_diff -d -f camera-1-4096spp.png ../rnd-pbrt-v4-001/kroken-001.png diff-001.jpg differing pixels: 19.980% (112387 of 562500) average difference: 1.529% maximum difference: 18.573% Summary: Many pixels differ. == "camera-1-4096spp.png" and "../rnd-pbrt-v4-001/kroken-001.png" are different </code></pre> Most prominent is the difference in the black background of the head sculpture on the upper left shelf, and the wall behind the glasses. PBRT v4 - Part I: Kroken Scene 2023-07-03T00:00:00+00:00 The fourth edition</a> of the Physically Based Rendering book was released this year (in 2023). The C++ source code is available on GitHub</a> and after compiling it (via CMake</a>) I wanted to render my first picture: The nice thing about pbrt-v4</code> is that we can watch the resulting image being rendered via tev</a>. First start the EXR Viewer</code>: $ tev 12:21:30 SUCCESS Initialized IPC, listening on 127.0.0.1:14158 12:21:30 INFO Loading window... 12:22:18 INFO Accepted IPC client connection into socket fd 34 (host: 127.0.0.1:38522) 12:23:42 SUCCESS Loaded 'camera-1.exr (16590)' via IPC after 0.013 seconds. 12:24:47 INFO Client disconnected from socket fd 34 12:30:10 INFO Accepted IPC client connection into socket fd 34 (host: 127.0.0.1:52838) ... </code></pre> Then connect to the viewer by using the --display-server</code> command line option: $ time ./pbrt --stats --spp 4096 --display-server localhost:14158 ../../pbrt-v4-scenes/kroken/camera-1.pbrt pbrt version 4 (built Jul 3 2023 at 12:16:24) Copyright (c)1998-2021 Matt Pharr, Wenzel Jakob, and Greg Humphreys. The source code to pbrt (but *not* the book contents) is covered by the Apache 2.0 License. See the file LICENSE.txt for the conditions of the license. Warning: /media/datadisk3/git/github/pbrt-v4-scenes/kroken/lights.pbrt:7:4: Converting non-RGB "L" parameter to RGB so that a portal light can be used. Rendering: [+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++] (4134.9s) Statistics: BVH Interior nodes 287361520 Leaf nodes 287361531 Nodes visited 1696162946832 Primitives per leaf node 287902422 / 287361531 (1.00x) Geometry Spheres 2 Triangles added from displacement mapping 247702869 Buffer cache hits 239 / 955 (25.03%) Triangles per mesh 287904585 / 248 (1160905.58x) Integrator Camera rays traced 2304000000 Surface interactions 8840973743 Volume interactions 20663051 Intersections Regular ray intersection tests 15575663309 Ray-Triangle intersection tests 18868481914 / 86881406902 (0.22x) Memory BVH 19.27 GiB Film pixels 103.00 MiB Image maps 159.38 MiB Light BVH 184.91 kB Primitives 4.29 GiB Redundant vertex and index buffers 347.69 MiB Tokenizer buffers 244.50 kB Triangles 2.15 GiB Unreported / unused 16.97 GiB Scene AreaLights 2175 Lights 2176 Materials 80 Object instances created 10 Textures 164 real 70m24,642s user 1891m16,519s sys 1m47,339s </code></pre> Compiling</h2> $ cmake --version cmake version 3.26.4 CMake suite maintained and supported by Kitware (kitware.com/cmake). $ pwd /media/datadisk3/git/github/pbrt-v4 $ mkdir build $ cd build/ $ cmake .. -- The CXX compiler identification is GNU 9.4.0 -- The C compiler identification is GNU 9.4.0 -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Setting build type to 'Release' as none was specified. -- Found Git: /home/linuxbrew/.linuxbrew/bin/git (found version "2.41.0") -- OpenEXR at commit: 5cfb5dab6dfada731586b0281bdb15ee75e26782 -- OpenVDB at commit: 414bed84c2fc22e188eac7b611aa85c7edd7a5a9 -- Ptex at commit: 4cd8e9a6db2b06e478dfbbd8c26eb6df97f84483 -- double-conversion at commit: cc1f75a114aca8d2af69f73a5a959aecbab0e87a -- filesystem at commit: c5f9de30142453eb3c6fe991e82dfc2583373116 -- glfw at commit: 4cb36872a5fe448c205d0b46f0e8c8b57530cfe0 -- libdeflate at commit: 1fd0bea6ca2073c68493632dafc4b1ddda1bcbc3 -- lodepng at commit: 8c6a9e30576f07bf470ad6f09458a2dcd7a6a84a -- qoi at commit: 028c75fd26e5e0758c7c711216c00404994c1ad3 -- stb at commit: af1a5bc352164740c1cc1354942b1c6b72eacb8a -- utf8proc at commit: 2484e2ed5e1d9c19edcccf392a7d9920ad90dfaf -- zlib at commit: 54d591eabf9fe0e84c725638f8d5d8d202a093fa -- Performing Test CMAKE_HAVE_LIBC_PTHREAD -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE -- Found OpenGL: /usr/lib/x86_64-linux-gnu/libOpenGL.so -- The ASM compiler identification is GNU -- Found assembler: /usr/bin/cc CMake Warning (dev) at src/ext/libdeflate/CMakeLists.txt:12 (option): Policy CMP0077 is not set: option() honors normal variables. Run "cmake --help-policy CMP0077" for policy details. Use the cmake_policy command to set the policy and suppress this warning. For compatibility with older versions of CMake, option is clearing the normal variable 'BUILD_SHARED_LIBS'. This warning is for project developers. Use -Wno-dev to suppress it. -- Performing Test DEFLATE_LINT_WALL -- Performing Test DEFLATE_LINT_WALL - Success -- Performing Test DEFLATE_LINT_WUNDEF -- Performing Test DEFLATE_LINT_WUNDEF - Success -- Performing Test DEFLATE_LINT_PEDANTIC -- Performing Test DEFLATE_LINT_PEDANTIC - Success -- Performing Test DEFLATE_LINT_DECLARATION_AFTER_STATEMENT -- Performing Test DEFLATE_LINT_DECLARATION_AFTER_STATEMENT - Success -- Performing Test DEFLATE_LINT_MISSING_PROTOTYPES -- Performing Test DEFLATE_LINT_MISSING_PROTOTYPES - Success -- Performing Test DEFLATE_LINT_STRICT_PROTOTYPES -- Performing Test DEFLATE_LINT_STRICT_PROTOTYPES - Success -- Performing Test DEFLATE_LINT_VLA -- Performing Test DEFLATE_LINT_VLA - Success -- Performing Test DEFLATE_LINT_IMPLICIT_FALLTHROUGH -- Performing Test DEFLATE_LINT_IMPLICIT_FALLTHROUGH - Success -- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.11") -- Could NOT find Imath (missing: Imath_DIR) -- Could NOT find IlmBase (missing: IlmBase_DIR) -- Could NOT find OpenEXR (missing: OpenEXR_DIR) -- Found PkgConfig: /home/linuxbrew/.linuxbrew/bin/pkg-config (found version "0.29.2") -- Found OpenEXR: /usr/include (found suitable version "2.3.0", minimum required is "2.3") -- Found OpenEXR version 2.3.0 CMake Deprecation Warning at src/ext/ptex/CMakeLists.txt:1 (cmake_minimum_required): Compatibility with CMake < 2.8.12 will be removed from a future version of CMake. Update the VERSION argument <min> value or use a ...<max> suffix to tell CMake that the project does not need compatibility with older versions. -- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE) -- Including X11 support -- Found X11: /usr/include -- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so -- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so - found -- Looking for gethostbyname -- Looking for gethostbyname - found -- Looking for connect -- Looking for connect - found -- Looking for remove -- Looking for remove - found -- Looking for shmat -- Looking for shmat - found -- Looking for IceConnectionNumber in ICE -- Looking for IceConnectionNumber in ICE - found -- Unable to find -lprofiler -- Looking for a CUDA compiler -- Looking for a CUDA compiler - /usr/local/cuda/bin/nvcc -- Found CUDA: /usr/local/cuda (found version "11.0") -- Found CUDA: 11.0.221 CMake Warning at CMakeLists.txt:189 (message): Found CUDA but PBRT_OPTIX7_PATH is not set. Disabling GPU compilation. -- Performing Test COMPILER_SUPPORTS_MARCH_NATIVE -- Performing Test COMPILER_SUPPORTS_MARCH_NATIVE - Success -- Performing Test HAVE_MMAP -- Performing Test HAVE_MMAP - Success -- Performing Test HAS_INTRIN_H -- Performing Test HAS_INTRIN_H - Failed -- Performing Test HAVE_DECLSPEC_NOINLINE -- Performing Test HAVE_DECLSPEC_NOINLINE - Failed -- Performing Test HAVE_ATTRIBUTE_NOINLINE -- Performing Test HAVE_ATTRIBUTE_NOINLINE - Success -- Performing Test HAVE_PRE_POST_BAR_RESTRICT -- Performing Test HAVE_PRE_POST_BAR_RESTRICT - Success -- Performing Test HAVE_PRE_BAR_RESTRICT -- Performing Test HAVE_PRE_BAR_RESTRICT - Success -- Performing Test HAVE__ALIGNED_MALLOC -- Performing Test HAVE__ALIGNED_MALLOC - Failed -- Performing Test HAVE_POSIX_MEMALIGN -- Performing Test HAVE_POSIX_MEMALIGN - Success -- Performing Test INT64_IS_OWN_TYPE -- Performing Test INT64_IS_OWN_TYPE - Failed -- Configuring done (5.8s) -- Generating done (0.1s) -- Build files have been written to: /media/datadisk3/git/github/pbrt-v4/build $ cmake --build . ... [100%] Linking CXX executable cctest [100%] Built target cctest </code></pre> Using imgtool</h2> Above is a slightly modified version using the imgtool</code> (which comes with pbrt-v4</code>) to convert the OpenEXR</a> file to PNG</a> and apply a whitebalance</code>: $ ./imgtool whitebalance --temperature 6200 camera-1.exr --outfile wb-camera-1.exr $ ./imgtool convert --aces-filmic wb-camera-1.exr --outfile camera-1.png </code></pre> The difference is a bit hard to catch by eye, but the imf_diff</code> tool helps to see it, using false-color</code>: $ imf_diff -d -f kroken-001.png camera-1.png diff-001.jpg differing pixels: 98.718% (555290 of 562500) average difference: 7.245% maximum difference: 9.987% Summary: Many pixels differ slightly. == "kroken-001.png" and "camera-1.png" are different </code></pre> camera-4</h2> There are seven camera perspectives of the same scene (kroken</code>) shipping with the current version of the repository</a> full of pbrt-v4-scenes</code>. Here's another example, how the scene looks like from camera-4</code>: And the resulting statistics: $ time ./pbrt --stats --spp 4096 --display-server localhost:14158 ../../pbrt-v4-scenes/kroken/camera-4.pbrt pbrt version 4 (built Jul 3 2023 at 12:16:24) Copyright (c)1998-2021 Matt Pharr, Wenzel Jakob, and Greg Humphreys. The source code to pbrt (but *not* the book contents) is covered by the Apache 2.0 License. See the file LICENSE.txt for the conditions of the license. Warning: /media/datadisk3/git/github/pbrt-v4-scenes/kroken/lights.pbrt:7:4: Converting non-RGB "L" parameter to RGB so that a portal light can be used. Rendering: [+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++] (4612.3s) Statistics: BVH Interior nodes 287364302 Leaf nodes 287364313 Nodes visited 1640129095053 Primitives per leaf node 287904106 / 287364313 (1.00x) Geometry Spheres 2 Triangles added from displacement mapping 247704553 Buffer cache hits 239 / 955 (25.03%) Triangles per mesh 287906269 / 248 (1160912.38x) Integrator Camera rays traced 3221225472 Surface interactions 12319864491 Volume interactions 5000267 Intersections Regular ray intersection tests 19757521699 Ray-Triangle intersection tests 25378979959 / 123058811405 (0.21x) Memory BVH 19.27 GiB Film pixels 144.00 MiB Image maps 159.38 MiB Light BVH 184.91 kB Primitives 4.29 GiB Redundant vertex and index buffers 347.69 MiB Tokenizer buffers 244.55 kB Triangles 2.15 GiB Unreported / unused 17.76 GiB Scene AreaLights 2175 Lights 2176 Materials 80 Object instances created 10 Textures 164 real 78m25,715s user 2115m43,111s sys 1m39,895s </code></pre> Currently this scene does not render with the Rust</a> version rs-pbrt</a> based on pbrt-v3</code>, but there are a couple of things which might get ported: The connection to tev</code> would allow to watch the renderer doing it's job.</li> Can we somehow use a denoiser?</li> Can the parser be adjusted to read pbrt-v4</code> scenes (maybe by adding some missing materials)?</li> </ol> Blender to Arnold Export - Part III: Base Color 2023-06-20T00:00:00+00:00 The last part (Blender to Arnold Export - Part II: Cameras</a>) talked about exporting the geometry from Blender</a> to Arnold</a>, but ignoring shaders, because we didn't define them for Arnold, nor did we have lights to illuminate the scene. Now I wanted to see at least some colors: On the left you see Blender's Material Preview</code> in Blender's 3D Viewport</code> and on the right Arnold's rendered image, after exporting some utility</code> shaders. We use only the color</code> of the shader, by getting a value from Blender and exporting it to the utility</code> shader. Here an example: $ grep 'Material.181' blender_35_splash_nicole_morena_shaders.ass -A 2 -B 2 utility { name Material.181 color 0.375748932 0.244087651 0.167510375 } </code></pre> More information about the utility</code> shader and it's parameters: $ /usr/local/Arnold/bin/kick -info utility node: utility type: shader output: RGB parameters: 8 multioutputs: 0 filename: <built-in> version: 7.2.2.0 Type Name Default ------------ -------------------------------- -------------------------------- ENUM color_mode color ENUM shade_mode ndoteye ENUM overlay_mode none RGB color 1, 1, 1 FLOAT ao_distance 100 FLOAT roughness 0.2 VECTOR normal 0, 0, 0 STRING name </code></pre> The default values for color_mode</code> and shade_mode</code> work fine for our purpose, because ndoteye</code> allows us to render without lights. I splitted the output files into two files, by providing some new options to the blender/io_scene_ass</a> files, responsible for the Arnold .ass</code> file export. The first option use_shader_file</code> will create an additional file (named *_shaders.ass</code>), whereas the second option use_shader_file_only</code> allows omitting the main .ass</code> file, which can be useful, once you exported the geometry (which can be a huge file and take some time to export). Anyway, how do you render those two .ass</code> files with Arnold from the command line? It's pretty simple, you just mention those files in the right order, e.g.: $ kick blender_35_splash_nicole_morena_shaders.ass blender_35_splash_nicole_morena.ass ... </code></pre> I didn't print the additional options</code> I used for rendering, but you can always ask Arnold for help, by calling kick -h</code>. Blender to Arnold Export - Part II: Cameras 2023-06-19T00:00:00+00:00 The last part (Blender to Arnold Export - Part I: The Addon</a>) introduced the Blender addon without talking really about the Python</a> code behind it. The Python code already supported exporting polymesh</code> nodes to Arnold (using the Python API of Blender</a> and Arnold</a>). The splash screen scene for Blender 3.5.1 contains 2012</code> such nodes: $ grep polymesh ~/Downloads/blender_35_splash_nicole_morena.ass | wc -l 2012 </code></pre> But to be able to render something we need at least a camera node. Arnold knows several of those camera nodes: $ /usr/local/Arnold/bin/kick -nodes n | grep camera camera_projection shader cyl_camera camera fisheye_camera camera ortho_camera camera persp_camera camera spherical_camera camera uv_camera camera vr_camera camera </code></pre> But for now lets start with just a ortho_camera</code> node (needed for the splash screen scene), and a persp_camera</code> node (for most other scenes). Lets first look at the resulting image: At that point I was still using an Arnold persp_camera</code> node and zoomed in a bit to match the Blender viewport, but I fixed that later by providing the Arnold ortho_camera</code> node: So the code I added to the already existing Python code can be seen here in the output of git diff</code>: diff --git a/blender/io_scene_ass/export_ass.py b/blender/io_scene_ass/export_ass.py index d57f389..ef11aaf 100644 --- a/blender/io_scene_ass/export_ass.py +++ b/blender/io_scene_ass/export_ass.py @@ -1,8 +1,11 @@ # SPDX-License-Identifier: GPL-2.0-or-later +# Python modules +import math import os -import sys import platform +import sys +# Blender modules import bpy from mathutils import Matrix #, Vector, Color #from bpy_extras import io_utils, node_shader_utils @@ -61,6 +64,11 @@ class AssExporter: arnold.AiBegin() # we need an arnold universe below universe = arnold.AiUniverse() + # options + options = arnold.AiUniverseGetOptions(universe) + # get camera (used for rendering) from scene + scene = bpy.context.scene + camera_name = scene.camera.name # Blender objects EXPORT_GLOBAL_MATRIX = Matrix() depsgraph = context.evaluated_depsgraph_get() @@ -88,7 +96,66 @@ class AssExporter: except RuntimeError: me = None if me is None: - print('WARNING: ignore "%s" ...' % ob.name) + if ob.type == 'CAMERA': + if ob.name == camera_name: + percent = scene.render.resolution_percentage / 100.0 + xresolution = int(scene.render.resolution_x * percent) + yresolution = int(scene.render.resolution_y * percent) + # xres + arnold.AiNodeSetInt(options, "xres", xresolution) + # yres + arnold.AiNodeSetInt(options, "yres", yresolution) + if ob.data.type == 'ORTHO': + # ortho_camera + camera = arnold.AiNode(universe, + "ortho_camera", + camera_name) + # screen_window + ortho_scale = ob.data.ortho_scale / 2.0 + arnold.AiNodeSetVec2(camera, + "screen_window_min", + -ortho_scale, -ortho_scale) + arnold.AiNodeSetVec2(camera, + "screen_window_max", + ortho_scale, ortho_scale) + else: + # persp_camera + camera = arnold.AiNode(universe, + "persp_camera", + camera_name) + # fov + aspect = xresolution / float(yresolution) + if aspect >= 1.0: + fov = math.degrees(ob.data.angle) + else: + fov = 2 * math.degrees(math.atan((aspect * 16.0) / lens)) + arnold.AiNodeSetFlt(camera, "fov", fov) + # options needs a link to camera + arnold.AiNodeSetPtr(options, "camera", camera) + # matrix + am = arnold.AtMatrix() + arnold.AiM4Identity(am) + am[0][0] = ob_mat[0][0] + am[0][1] = ob_mat[1][0] + am[0][2] = ob_mat[2][0] + am[0][3] = ob_mat[3][0] + am[1][0] = ob_mat[0][1] + am[1][1] = ob_mat[1][1] + am[1][2] = ob_mat[2][1] + am[1][3] = ob_mat[3][1] + am[2][0] = ob_mat[0][2] + am[2][1] = ob_mat[1][2] + am[2][2] = ob_mat[2][2] + am[2][3] = ob_mat[3][2] + am[3][0] = ob_mat[0][3] + am[3][1] = ob_mat[1][3] + am[3][2] = ob_mat[2][3] + am[3][3] = ob_mat[3][3] + arnold.AiNodeSetMatrix(camera, "matrix", am) + else: + print('WARNING: ignore "%s" ...' % ob.name) + else: + print('WARNING: ignore "%s" ...' % ob.name) continue # _must_ do this first since it re-allocs arrays mesh_triangulate(me) @@ -122,6 +189,7 @@ class AssExporter: ##print('DEBUG: obnamestring = %s' % obnamestring) # arnold polymesh = arnold.AiNode(universe, "polymesh", obnamestring) + arnold.AiNodeSetBool(polymesh, "smoothing", False) vlist = arnold.AiArrayAllocate(len(me_verts), 1, arnold.AI_TYPE_VECTOR) numVertexIndices = 0 </code></pre> The first couple of lines just give access to the Arnold options</code> node, which later will link back to the camera node we will create (and set the render resolution, which we get from Blender). $ grep options blender_35_splash_nicole_morena.ass -A 5 options { xres 1327 yres 1250 camera "CAM-wide" } </code></pre> If we just search for camera</code> we see how that link works, it mentions the name</code> of a node, which in this case has a type of ortho_camera</code>: $ grep camera blender_35_splash_nicole_morena.ass camera "CAM-wide" ortho_camera </code></pre> The node itself and it's name can be seen here: $ grep ortho_camera blender_35_splash_nicole_morena.ass -A 10 ortho_camera { name CAM-wide matrix 0.637181938 0.770702124 -0.00418198621 0 -0.198978737 0.169744015 0.965191424 0 0.744584918 -0.614170372 0.261511147 0 8.4063282 -6.93524885 4.93189812 1 screen_window_min -1.97714305 -1.97714305 screen_window_max 1.97714305 1.97714305 } </code></pre> So we also export the matrix</code> and four values (two VECTOR2</code> parameters) to define the screen_window</code> settings of the Arnold ortho_camera</code> node: $ /usr/local/Arnold/bin/kick -info ortho_camera node: ortho_camera type: camera output: (null) parameters: 20 multioutputs: 0 filename: <built-in> version: 7.2.2.0 Type Name Default ------------ -------------------------------- -------------------------------- VECTOR[] position 0, 0, 0 VECTOR[] look_at 0, 0, -1 VECTOR[] up 0, 1, 0 MATRIX[] matrix identity ENUM handedness right FLOAT near_clip 0.0001 FLOAT far_clip 1e+30 VECTOR2[] screen_window_min -1, -1 VECTOR2[] screen_window_max 1, 1 FLOAT shutter_start 0 FLOAT shutter_end 0 ENUM shutter_type box VECTOR2[] shutter_curve (empty) ENUM rolling_shutter off FLOAT rolling_shutter_duration 0 FLOAT motion_start 0 FLOAT motion_end 1 FLOAT exposure 0 NODE filtermap (null) STRING name </code></pre> For now we do not care about the other parameters. Let's check what else is missing right now instead: $ /usr/local/blender-3.5.1-linux-x64/blender Read prefs: /home/jan/.config/blender/3.5/config/userpref.blend Read blend: /home/jan/Downloads/blender_35_splash_nicole_morena.blend ... 00:00:00 3712MB | log started Mon Jun 19 12:28:34 2023 00:00:00 3712MB | Arnold 7.2.2.0 ... ... WARNING: ignore "CAM-closeup" ... WARNING: ignore "Mball.001" ... WARNING: ignore "Mball.002" ... WARNING: ignore "Point.011" ... WARNING: ignore "Point.010" ... WARNING: ignore "Point.008" ... WARNING: ignore "Light" ... WARNING: ignore "Area" ... WARNING: ignore "Area.002" ... WARNING: ignore "Point.001" ... WARNING: ignore "Area.003" ... WARNING: ignore "Area.004" ... WARNING: ignore "Point.009" ... WARNING: ignore "Point.007" ... WARNING: ignore "Area.001" ... WARNING: ignore "Point" ... 00:00:44 6766MB | [ass] writing scene to /home/jan/Downloads/blender_35_splash_nicole_morena.ass (mask=0xFFFF) ... 00:00:47 6765MB | [ass] wrote 156391329 bytes, 2014 nodes in 0:03.26 00:00:48 6765MB | 00:00:48 6765MB | releasing resources 00:00:48 6765MB | unloading 3 plugins 00:00:48 6765MB | closing usd_proc.so ... 00:00:48 6765MB | closing cryptomatte.so ... 00:00:48 6765MB | closing alembic_proc.so ... 00:00:48 6764MB | unloading plugins done 00:00:48 6764MB | Arnold shutdown </code></pre> Most of the ignored Blender nodes are lights, which we would need next, so we can render using shaders. ... class AssExporter: def __init__(self): self.filename = None def export(self, context, filename): self.filename = filename # AiBegin arnold.AiBegin() ... for collection in bpy.data.collections: if collection.hide_render or collection.use_fake_user: continue else: objects = collection.objects for i, ob_main in enumerate(objects): # ignore dupli children if ob_main.parent and ob_main.parent.instance_type in {'VERTS', 'FACES'}: continue obs = [(ob_main, ob_main.matrix_world)] if ob_main.is_instancer: obs = [] obs += [(dup.instance_object.original, dup.matrix_world.copy()) for dup in depsgraph.object_instances if dup.parent and dup.parent.original == ob_main] for ob, ob_mat in obs: ob_for_convert = ob.evaluated_get(depsgraph) try: me = ob_for_convert.to_mesh() except RuntimeError: me = None if me is None: if ob.type == 'CAMERA': if ob.name == camera_name: ... else: print('WARNING: ignore "%s" ...' % ob.name) else: print('WARNING: ignore "%s" ...' % ob.name) continue ... # AiSceneWrite params = arnold.AiParamValueMap() mask = arnold.AI_NODE_ALL arnold.AiParamValueMapSetInt(params, "mask", mask) arnold.AiParamValueMapSetBool(params, "binary", False) arnold.AiSceneWrite(universe, filename, params) # AiEnd arnold.AiEnd() ... </code></pre> The Arnold image above was rendered using the -is</code> option: $ /usr/local/Arnold/bin/kick -h | grep '\-is ' -is Ignore shaders </code></pre> Like this (omitting other options used to render the .ass</code> file): $ /usr/local/Arnold/bin/kick -is blender_35_splash_nicole_morena.ass ... </code></pre> Blender to Arnold Export - Part I: The Addon 2023-06-17T00:00:00+00:00 Wouldn't it be great if you could just download the latest Blender</a> release, install it, run it, click on the Release Notes</code> of the splash screen, download the Blender scene being used (to create the splash screen), load the scene into Blender, and render it there via Cycles, just to get a feeling for how long things would take to render such an image? Well, you can do that, but what about other renderers, like Arnold</a>? I already had a project Arnold</code> on Codeberg</a>, so I added a sub-folder called blender/io_scene_ass</a>, and you currently just need to create a softlink to make Blender find the addon: $ pwd /usr/local/blender-3.5.1-linux-x64/3.5/scripts/addons $ ls -lag io_scene_ass lrwxrwxrwx 1 root 57 Mai 5 19:11 io_scene_ass -> /media/datadisk3/git/codeberg/Arnold/blender/io_scene_ass </code></pre> It contains currently only two files, __init__.py</code>, and export_ass.py</code>, but before we discuss Python</a> code, let's just explain how to install the addon (for now). Open the Blender Preferences</code> windows and activate the addon there: After that you should have a new entry in File->Export</code>: This blog post is more about making you aware of this addon than using it or showing the first images. But there will be more blog posts about this topic ... Abridge Zola Theme 2023-06-16T00:00:00+00:00 Abridge is a fast and lightweight Zola theme using semantic html, only ~6kb css before svg icons and syntax highlighting, no mandatory JS, and perfect Lighthouse</a>, YellowLabTools</a>, and Observatory</a> scores. Here is a Zola Themes Benchmarks</a> Page. Code Blocks and Themes 2022-05-16T00:00:00+00:00 This article shows various Code Blocks allowing to easily compare sublime themes. Markdown and Style Guide 2022-05-15T00:00:00+00:00 This article offers a sample of basic Markdown syntax that can be used in Zola content files, also it shows if basic HTML elements are decorated with CSS in a Zola theme. Embedded Youtube Videos 2021-05-08T00:00:00+00:00 Zola has many shortcodes, and new are easily added, this example shows youtube. Embedded Vimeo Videos 2021-05-07T00:00:00+00:00 Zola has many shortcodes, and new are easily added, this example shows vimeo. Mathematical Notations 2021-05-05T00:00:00+00:00 You can use KaTeX</a> to render mathematical notations. You can enable the $\KaTeX$ support globally, per-section or per-page basis.

Jan Walter R&D

Blender to Arnold Export - Part IV: Blender 4.0 Splash Screen

Guerilla 2.3.43 is Here!

Use Python and Qt for a Skat game helper

Writing to a File</h1> You might have noticed that the first screenshot (without the counters) showed an option at the lower left, called Select two Skat cards first</code>. The reason for that was that this version was writing a simple file to disk, which looks like this:</p>

PBRT and Tev

Rust and Godot 4

Language Server Protocol - Helix and Emacs

PBRT v4 - Part III: Watercolor Scene - denoised

PBRT v4 - Part II: OptiX denoiser

imgtool</h2> After a successful compilation there should be an command</code> for denoising:</p>

Denoising</h2> So, after rendering the camera-1</code> with only a few samples per pixel (--spp 16</code>):</p>

PBRT v4 - Part I: Kroken Scene

Using imgtool</h2> </p>

Blender to Arnold Export - Part III: Base Color

Blender to Arnold Export - Part II: Cameras

Blender to Arnold Export - Part I: The Addon

Abridge Zola Theme

Code Blocks and Themes

Markdown and Style Guide

Embedded Youtube Videos

Embedded Vimeo Videos

Mathematical Notations