Deploy GH

api/latest/_gi_methods.html

@@ -103,24 +103,24 @@
 <li class="level1"><a href="#GiPPPCC">Per Pixel PCC</a><ul><li class="level2"><a href="#GiPPGridPlacement">PCC Per Pixel Grid Placement</a></li>
 </ul>
 </li>
-<li class="level1"><a href="#GiInstantRadiosity">Instant Radiosity</a><ul><ul><li class="level3"><a href="#autotoc_md89">Pros</a></li>
-<li class="level3"><a href="#autotoc_md90">Cons</a></li>
+<li class="level1"><a href="#GiInstantRadiosity">Instant Radiosity</a><ul><ul><li class="level3"><a href="#autotoc_md90">Pros</a></li>
+<li class="level3"><a href="#autotoc_md91">Cons</a></li>
 </ul>
 </ul>
 </li>
-<li class="level1"><a href="#GiIrradianceVolume">Irradiance Volume</a><ul><ul><li class="level3"><a href="#autotoc_md91">Pros</a></li>
-<li class="level3"><a href="#autotoc_md92">Cons</a></li>
+<li class="level1"><a href="#GiIrradianceVolume">Irradiance Volume</a><ul><ul><li class="level3"><a href="#autotoc_md92">Pros</a></li>
+<li class="level3"><a href="#autotoc_md93">Cons</a></li>
 </ul>
 </ul>
 </li>
-<li class="level1"><a href="#GiVCT">Voxel Cone Tracing (aka VCT)</a><ul><ul><li class="level3"><a href="#autotoc_md93">Pros</a></li>
-<li class="level3"><a href="#autotoc_md94">Cons</a></li>
+<li class="level1"><a href="#GiVCT">Voxel Cone Tracing (aka VCT)</a><ul><ul><li class="level3"><a href="#autotoc_md94">Pros</a></li>
+<li class="level3"><a href="#autotoc_md95">Cons</a></li>
 </ul>
 <li class="level2"><a href="#GiVCTPlusPPPCC">VCT + Per Pixel PCC Hybrid</a></li>
 </ul>
 </li>
-<li class="level1"><a href="#GiIFD">Irradiance Field with Depth (IFD)</a><ul><ul><li class="level3"><a href="#autotoc_md95">Pros</a></li>
-<li class="level3"><a href="#autotoc_md96">Cons</a></li>
+<li class="level1"><a href="#GiIFD">Irradiance Field with Depth (IFD)</a><ul><ul><li class="level3"><a href="#autotoc_md96">Pros</a></li>
+<li class="level3"><a href="#autotoc_md97">Cons</a></li>
 </ul>
 </ul>
 </li>
@@ -210,7 +210,7 @@ <h1><a class="anchor" id="GiInstantRadiosity"></a>
 <p>It is based on an old <a href="https://www.gamedev.net/blogs/entry/1925299-deferred-lighting-and-instant-radiosity/">gamedev.net article</a>.</p>
 <p>The technique consist in doing raytracing from the light points of view into all directions. And whenever there is a hit place a 'virtual point light' which is literally a basic point that emits light, mimicking a light bounce</p>
 <p>Another way to see this technique is that it's just placing an arbitrary amount of point lights until the scene is lit enough from many locations. But instead of the lights being placed by artists, it's done automatically.</p>
-<h3><a class="anchor" id="autotoc_md89"></a>
+<h3><a class="anchor" id="autotoc_md90"></a>
 Pros</h3>
 <ol type="1">
 <li>Lots of parameter to tune. The more VPLs you have, the more accurate the solution will be but higher the performance cost</li>
@@ -220,7 +220,7 @@ <h3><a class="anchor" id="autotoc_md89"></a>
 <li>Camera independent</li>
 <li>Can be enabled at the same time as PCC, and PCC can provide information about specular reflections and sky</li>
 </ol>
-<h3><a class="anchor" id="autotoc_md90"></a>
+<h3><a class="anchor" id="autotoc_md91"></a>
 Cons</h3>
 <ol type="1">
 <li>Requires Forward+ to be active</li>
@@ -241,7 +241,7 @@ <h1><a class="anchor" id="GiIrradianceVolume"></a>
 <p>Irradiance Volume uses a 3D volume to store lighting information. Currently this IV is generated from Instant Radiosity data. But once generated the 3D texture can be saved to disk as is and be loaded directly which should be very fast (only limitation is IO bandwidth)</p>
 <p>Each voxel contains lighting information from all 6 directions.</p>
 <p>Another way to look at this solution is like a 3D grid of lots of 1x1 cubemaps.</p>
-<h3><a class="anchor" id="autotoc_md91"></a>
+<h3><a class="anchor" id="autotoc_md92"></a>
 Pros</h3>
 <ol type="1">
 <li>Extremely fast</li>
@@ -250,7 +250,7 @@ <h3><a class="anchor" id="autotoc_md91"></a>
 <li>Camera independent</li>
 <li>Can be enabled at the same time as PCC, and PCC can provide information about specular reflections and sky</li>
 </ol>
-<h3><a class="anchor" id="autotoc_md92"></a>
+<h3><a class="anchor" id="autotoc_md93"></a>
 Cons</h3>
 <ol type="1">
 <li>Quality/accuracy depends on how dense the grid is. Big scenes may need very large resolution. 3D volume textures quickly grow in VRAM usage. e.g. a 16x16x16 needs only 16kb of VRAM, whereas a 128x128x128 volume needs 8MB and 256x256x256 needs 64MB</li>
@@ -269,7 +269,7 @@ <h1><a class="anchor" id="GiVCT"></a>
 <p>As of 2021 this technique is state of the art and is <em>very</em> accurate and can even generate specular glossy reflections, although low roughness reflections will not look as good as high roughness reflections.</p>
 <p>This technique works by voxelizing the entire scene (i.e. turning the whole scene into a Minecraft-like world representation) and then at runtime cone tracing against this voxel world to gather bounce data.</p>
 <p><img src="VCT.jpg" alt="" class="inline"/></p>
-<h3><a class="anchor" id="autotoc_md93"></a>
+<h3><a class="anchor" id="autotoc_md94"></a>
 Pros</h3>
 <ol type="1">
 <li>Extremely accurate</li>
@@ -294,7 +294,7 @@ <h3><a class="anchor" id="autotoc_md93"></a>
 <li>Camera independent</li>
 <li>Specular rough reflections supported</li>
 </ol>
-<h3><a class="anchor" id="autotoc_md94"></a>
+<h3><a class="anchor" id="autotoc_md95"></a>
 Cons</h3>
 <ol type="1">
 <li>Massive amounts of VRAM required</li>
@@ -324,7 +324,7 @@ <h1><a class="anchor" id="GiIFD"></a>
 <p>As of 2021 this technique is also state of the art and can be very accurate.</p>
 <p>This technique is extremely similar to <code>Irradiance Volume</code> before (e.g. can be thought of a 3D grid of 1x1 cubemaps), but it is combined with depth information to fight leaking.</p>
 <p>Additionally, instead of 3D textures, a 2D texture is used and octahedral maps are used to store information. The use of 2D textures instead of 3D opens up unexplored possibilities such as streaming 2D data using MPEG video compression, or GPU-friendly compression formats such as BC7 or ASTC.</p>
-<h3><a class="anchor" id="autotoc_md95"></a>
+<h3><a class="anchor" id="autotoc_md96"></a>
 Pros</h3>
 <ol type="1">
 <li>Very accurate</li>
@@ -351,7 +351,7 @@ <h3><a class="anchor" id="autotoc_md95"></a>
 <li>Can be enabled at the same time as per pixel PCC, and PCC can provide information about specular reflections and sky. If VCT is also enabled, See VCT + PCC hybrid section.</li>
 <li>When generated off rasterization, sky information is included.</li>
 </ol>
-<h3><a class="anchor" id="autotoc_md96"></a>
+<h3><a class="anchor" id="autotoc_md97"></a>
 Cons</h3>
 <ol type="1">
 <li>Some artifacts may appear<ol type="a">

api/latest/_gi_methods.js

@@ -22,22 +22,22 @@ var _gi_methods =
     [ "What technique should I choose?", "_gi_methods.html#GiWhatTechniqueChoose", null ],
     [ "Image Voxel Cone Tracing", "_image_voxel_cone_tracing.html", [
       [ "Step 1: Image Voxelizer", "_image_voxel_cone_tracing.html#IVCT_Step1", [
-        [ "Pros", "_gi_methods.html#autotoc_md89", null ],
-        [ "Cons", "_gi_methods.html#autotoc_md90", null ],
-        [ "Pros", "_gi_methods.html#autotoc_md91", null ],
-        [ "Cons", "_gi_methods.html#autotoc_md92", null ],
-        [ "Pros", "_gi_methods.html#autotoc_md93", null ],
-        [ "Cons", "_gi_methods.html#autotoc_md94", null ],
-        [ "Pros", "_gi_methods.html#autotoc_md95", null ],
-        [ "Cons", "_gi_methods.html#autotoc_md96", null ],
+        [ "Pros", "_gi_methods.html#autotoc_md90", null ],
+        [ "Cons", "_gi_methods.html#autotoc_md91", null ],
+        [ "Pros", "_gi_methods.html#autotoc_md92", null ],
+        [ "Cons", "_gi_methods.html#autotoc_md93", null ],
+        [ "Pros", "_gi_methods.html#autotoc_md94", null ],
+        [ "Cons", "_gi_methods.html#autotoc_md95", null ],
+        [ "Pros", "_gi_methods.html#autotoc_md96", null ],
+        [ "Cons", "_gi_methods.html#autotoc_md97", null ],
         [ "Downside", "_image_voxel_cone_tracing.html#IVCT_Step1_Downside", [
-          [ "Non-researched solutions:", "_image_voxel_cone_tracing.html#autotoc_md100", null ]
+          [ "Non-researched solutions:", "_image_voxel_cone_tracing.html#autotoc_md101", null ]
         ] ],
-        [ "Trivia", "_image_voxel_cone_tracing.html#autotoc_md101", null ]
+        [ "Trivia", "_image_voxel_cone_tracing.html#autotoc_md102", null ]
       ] ],
       [ "Step 2: Row Translation", "_image_voxel_cone_tracing.html#IVCT_Step2", null ],
       [ "Step 3: Cascades", "_image_voxel_cone_tracing.html#IVCT_Step3", null ],
-      [ "Wait isn't this what UE5's Lumen does?", "_image_voxel_cone_tracing.html#autotoc_md102", null ],
-      [ "Wait isn't this what Godot does?", "_image_voxel_cone_tracing.html#autotoc_md103", null ]
+      [ "Wait isn't this what UE5's Lumen does?", "_image_voxel_cone_tracing.html#autotoc_md103", null ],
+      [ "Wait isn't this what Godot does?", "_image_voxel_cone_tracing.html#autotoc_md104", null ]
     ] ]
 ];

api/latest/_hlms_threading.html

@@ -163,7 +163,7 @@ <h1><a class="anchor" id="HlmsThreading_tidArgument"></a>
 <div class="ttc" id="aclass_ogre_1_1_hlms_html_a3b41b85c9b51fe6794d25e95bd5ea31f"><div class="ttname"><a href="class_ogre_1_1_hlms.html#a3b41b85c9b51fe6794d25e95bd5ea31f">Ogre::Hlms::kNoTid</a></div><div class="ttdeci">static constexpr size_t kNoTid</div><div class="ttdoc">For single-threaded operations.</div><div class="ttdef"><b>Definition:</b> OgreHlms.h:147</div></div>
 </div><!-- fragment --><p>If you're overriding the <a class="el" href="class_ogre_1_1_hlms.html" title="HLMS stands for &quot;High Level Material System&quot;.">Ogre::Hlms</a> class instead of <a class="el" href="class_ogre_1_1_hlms_listener.html" title="Listener that can be hooked to an Hlms implementation for extending it with custom code.">Ogre::HlmsListener</a>, the same rules apply. However you might override a function that is expected to be called from a worker thread but does not pass a tid value because the original Hlms implementations never needed it.</p>
 <p>The rule is that anything called as part of Ogre::Hlms::createShaderCacheEntry needs a tid, while everything else is called from the main thread.</p>
-<h2><a class="anchor" id="autotoc_md97"></a>
+<h2><a class="anchor" id="autotoc_md98"></a>
 API when OGRE_SHADER_COMPILATION_THREADING_MODE = 1</h2>
 <p>This option is used to facilitate porting from OgreNext 3.0.</p>
 <p>All listener functions still provide a tid value. However OgreNext provides setProperty/getProperty functions that don't ask for one. Therefore it is possible to do this:</p>
@@ -185,7 +185,7 @@ <h2><a class="anchor" id="autotoc_md97"></a>
 <div class="line">        }</div>
 <div class="line">    };</div>
 <div class="line">}</div>
-</div><!-- fragment --><h1><a class="anchor" id="autotoc_md98"></a>
+</div><!-- fragment --><h1><a class="anchor" id="autotoc_md99"></a>
 How does threaded Hlms work?</h1>
 <p>Hlms shaders are not randomly generated at any time from anywhere. It's not chaotic.</p>
 <p>Shader generation requests can originate from 3 locations:</p>
@@ -220,7 +220,7 @@ <h2><a class="anchor" id="autotoc_md97"></a>
 <p>That's why we must call <code>waitForHlmsJobs()</code> before calling <code>executeAllCommands()</code>.</p>
 <p>Therefore OgreNext will process and iterate through many Items while worker threads compile shaders that were seen for the first time.</p>
 <p>With a bit of luck, if the worker threads finish compiling before we reach <code>waitForHlmsJobs()</code> then there will be no stalls at all. If not, then the wait has likely reduced by a little. Furthermore, if multiple new PSOs are encountered, they will be delivered to different worker threads thus compiling in parallel.</p>
-<h2><a class="anchor" id="autotoc_md99"></a>
+<h2><a class="anchor" id="autotoc_md100"></a>
 What is the range of tid argument?</h2>
 <p>The range is <code>[0; num_threads)</code>. </p>
 </div></div><!-- contents -->

api/latest/_image_voxel_cone_tracing.html

@@ -133,13 +133,13 @@ <h2><a class="anchor" id="IVCT_Step1_Downside"></a>
 Downside</h2>
 <p>There is a downside of this (aside from VRAM usage): We need to voxelize each mesh + material combo. Meaning that if you have a mesh and want to apply different materials, we need to consume 2-3MB per material</p>
 <p>This is rarely a problem though because most meshes only use one set of materials. And for those that do, you may be able to get away with baking a material set that is either white or similar; the end results after calculating GI may not vary that much to worth the extra VRAM cost.</p>
-<h3><a class="anchor" id="autotoc_md100"></a>
+<h3><a class="anchor" id="autotoc_md101"></a>
 Non-researched solutions:</h3>
 <ul>
 <li>For simple colour swaps (e.g. RTS games, FPS with multiplayer teams), this should be workaroundeable by adding a single multiplier value, rather than voxelizing the mesh per material</li>
 <li>It should be possible to apply some sort of BC1-like compression, given that the mesh opaqueness and shape is the same. The only thing that changes is colour; thus a delta colour compression scheme could work well</li>
 </ul>
-<h2><a class="anchor" id="autotoc_md101"></a>
+<h2><a class="anchor" id="autotoc_md102"></a>
 Trivia</h2>
 <p>At first I panicked a little while developing the Image Voxelizer because the initial quality was far inferior than that of the original voxelizer.</p>
 <p>The problem was that the original VCT is a 'perfect' voxelization. i.e. if a triangle touches a single voxel, then that voxel adopts the colour of the triangle. Its neighbour voxels will remain empty. Simple. That results in a 'thin' voxel result.</p>
@@ -162,12 +162,12 @@ <h1><a class="anchor" id="IVCT_Step2"></a>
 <h1><a class="anchor" id="IVCT_Step3"></a>
 Step 3: Cascades</h1>
 <p><b>This step is currently a work in progress</b>. The implementation is planned to have N cascades (N user defined). During cone tracing, after we reach the end of a cascade we move on to the next cascade, which covers more ground but has coarser resolution, hence lower quality.</p>
-<h1><a class="anchor" id="autotoc_md102"></a>
+<h1><a class="anchor" id="autotoc_md103"></a>
 Wait isn't this what UE5's Lumen does?</h1>
 <p>AFAIK Lumen is also a Voxel Cone Tracer. Therefore it's normal there will be many similarities. I don't know if they use cascades though.</p>
 <p>As far as I've read, Lumen uses an entirely different approach to voxelizing which involves rasterizing from all 6 sides, which makes it very user hostile as meshes must be broken down to individual components (e.g. instead of submitting a house, each wall, column, floor and ceiling must be its own mesh).</p>
 <p>With Ogre-Next you just provide the mesh and it will just work (although with manual tunning you could achieve greater memory savings if e.g. the columns are split and voxelized separately).</p>
-<h1><a class="anchor" id="autotoc_md103"></a>
+<h1><a class="anchor" id="autotoc_md104"></a>
 Wait isn't this what Godot does?</h1>
 <p>Well, I was involved in <a href="https://godotengine.org/article/godot-40-gets-sdf-based-real-time-global-illumination">SDFGI advising Juan</a> on the subject, thus of course there are a lot of similarities.</p>
 <p>The main difference is that Godot generates a cascade of SDFs (signed distance fields), while Ogre-Next is generating a cascade of voxels.</p>

api/latest/_j_s_o_n-_materials.js

@@ -63,7 +63,7 @@ var _j_s_o_n__materials =
       ] ],
       [ "PBS Datablock Parameters", "hlmspbsdatablockref.html#dbPBSParameters", [
         [ "Parameter: brdf", "hlmspbsdatablockref.html#dbParamBRDF", null ],
-        [ "Parameter: refraction_strength", "hlmspbsdatablockref.html#autotoc_md110", null ],
+        [ "Parameter: refraction_strength", "hlmspbsdatablockref.html#autotoc_md111", null ],
         [ "Parameter: detail_diffuse[X]", "hlmspbsdatablockref.html#dbParamDetailDiffuse", null ],
         [ "Parameter: detail_normal[X]", "hlmspbsdatablockref.html#dbParamDetailNormal", null ],
         [ "Parameter: detail_weight", "hlmspbsdatablockref.html#dbParamDetailWeight", null ],

api/latest/_migrating_23_to_30.js

@@ -1,8 +1,8 @@
 var _migrating_23_to_30 =
 [
     [ "Resolving Merge Conflicts in Ogre-Next 3.0", "_resolving_merge_conflicts30.html", [
-      [ "Notes:", "_resolving_merge_conflicts30.html#autotoc_md75", null ],
-      [ "Batch Script", "_resolving_merge_conflicts30.html#autotoc_md76", null ]
+      [ "Notes:", "_resolving_merge_conflicts30.html#autotoc_md76", null ],
+      [ "Batch Script", "_resolving_merge_conflicts30.html#autotoc_md77", null ]
     ] ],
     [ "What's new in Ogre-Next 3.0", "_ogre30_changes.html", [
       [ "Ogre to OgreNext name migration", "_ogre30_changes.html#autotoc_md52", null ],
@@ -12,23 +12,23 @@ var _migrating_23_to_30 =
       [ "Move to C++11 and general cleanup", "_ogre30_changes.html#autotoc_md56", null ]
     ] ],
     [ "PBR / PBS Changes in 3.0", "_p_b_s_changes_in30.html", [
-      [ "Short version", "_p_b_s_changes_in30.html#autotoc_md62", null ],
-      [ "Long version", "_p_b_s_changes_in30.html#autotoc_md63", [
-        [ "Direct Lighting", "_p_b_s_changes_in30.html#autotoc_md64", [
-          [ "Fresnel Diffuse is no longer considered", "_p_b_s_changes_in30.html#autotoc_md65", [
-            [ "Raffaele's comments:", "_p_b_s_changes_in30.html#autotoc_md66", null ],
-            [ "Default-enable to diffuse fresnel", "_p_b_s_changes_in30.html#autotoc_md67", null ]
+      [ "Short version", "_p_b_s_changes_in30.html#autotoc_md63", null ],
+      [ "Long version", "_p_b_s_changes_in30.html#autotoc_md64", [
+        [ "Direct Lighting", "_p_b_s_changes_in30.html#autotoc_md65", [
+          [ "Fresnel Diffuse is no longer considered", "_p_b_s_changes_in30.html#autotoc_md66", [
+            [ "Raffaele's comments:", "_p_b_s_changes_in30.html#autotoc_md67", null ],
+            [ "Default-enable to diffuse fresnel", "_p_b_s_changes_in30.html#autotoc_md68", null ]
           ] ],
-          [ "Geometric Term change", "_p_b_s_changes_in30.html#autotoc_md68", null ],
-          [ "Metalness change", "_p_b_s_changes_in30.html#autotoc_md69", null ]
+          [ "Geometric Term change", "_p_b_s_changes_in30.html#autotoc_md69", null ],
+          [ "Metalness change", "_p_b_s_changes_in30.html#autotoc_md70", null ]
         ] ],
-        [ "IBL", "_p_b_s_changes_in30.html#autotoc_md70", [
-          [ "IBL Diffuse", "_p_b_s_changes_in30.html#autotoc_md71", [
-            [ "Multiplication by PI", "_p_b_s_changes_in30.html#autotoc_md72", null ]
+        [ "IBL", "_p_b_s_changes_in30.html#autotoc_md71", [
+          [ "IBL Diffuse", "_p_b_s_changes_in30.html#autotoc_md72", [
+            [ "Multiplication by PI", "_p_b_s_changes_in30.html#autotoc_md73", null ]
           ] ],
-          [ "IBL Specular", "_p_b_s_changes_in30.html#autotoc_md73", null ]
+          [ "IBL Specular", "_p_b_s_changes_in30.html#autotoc_md74", null ]
         ] ]
       ] ],
-      [ "Hemisphere Ambient Lighting changes", "_p_b_s_changes_in30.html#autotoc_md74", null ]
+      [ "Hemisphere Ambient Lighting changes", "_p_b_s_changes_in30.html#autotoc_md75", null ]
     ] ]
 ];

api/latest/_migrating_30_to_40.js

@@ -7,6 +7,7 @@ var _migrating_30_to_40 =
       ] ],
       [ "Compositor Script changes", "_ogre40_changes.html#autotoc_md59", null ],
       [ "New initialization step", "_ogre40_changes.html#autotoc_md60", null ],
-      [ "HlmsUnlit changes", "_ogre40_changes.html#autotoc_md61", null ]
+      [ "HlmsUnlit changes", "_ogre40_changes.html#autotoc_md61", null ],
+      [ "Header renames", "_ogre40_changes.html#autotoc_md62", null ]
     ] ]
 ];