<p dir="auto">Today I've upgraded our codebase from r88 -&gt; r91, everything seems to work fine aside from the reflectors (code which has not significantly changed since r88 from what I see). I've noticed that when checking individual upgrades, the problem starts at r90.</p>
<p dir="auto">It seems to go exponentially bad when our entire model + mirror are in the frustrum, when I'm right in front of it &amp; little else of the model, the performance is OK. Now since I can't provide live examples, I was wondering if someone could point me on where to look/investigate, or what could have changed in that release that affects them?</p>
<h5 dir="auto">Three.js version</h5>
<ul class="contains-task-list">
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> Dev</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox" checked=""> r91</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox" checked=""> r90</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> r89</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> r88</li>
</ul>
<h5 dir="auto">Browser</h5>
<ul class="contains-task-list">
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> All of them</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox" checked=""> Chrome</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> Firefox</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> Internet Explorer</li>
</ul>
<h5 dir="auto">OS</h5>
<ul class="contains-task-list">
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> All of them</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> Windows</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> macOS</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox" checked=""> Linux</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> Android</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> iOS</li>
</ul>
<h5 dir="auto">Hardware Requirements (graphics card, VR Device, ...)</h5>
<p dir="auto">Right now, there are two ways to adjust the positioning of a texture on an object:</p>
<ul dir="auto">
<li>UV coordinates in geometry</li>
<li><code class="notranslate">.offset</code> and <code class="notranslate">.repeat</code> properties on <code class="notranslate">Texture</code></li>
</ul>
<p dir="auto">It would be useful to also have <code class="notranslate">.offset</code> and <code class="notranslate">.repeat</code> properties on <code class="notranslate">Material</code> as well, so that these values could be varied on different objects without having to allocate additional geometries or texture resources.</p>
<p dir="auto">I'm considering an interesting use case: breaking down sky spheres/domes into smaller components. Rather than create a single, large, solid sphere, imagine a fraction of an icosahedron (subdivided) and repeated as multiple meshes to construct a sphere out of pieces. It would cost a few extra draw calls, but provide at least two benefits:</p>
<ol dir="auto">
<li>Significantly reduce the number of vertices computed by excluding the ones that are off camera, which is well more than half. Spheres can have hundreds of vertices, depending on the level of detail. This is not such a big deal on desktop, but I suspect it could make a big difference on mobile devices with <a href="https://en.wikipedia.org/wiki/Tiled_rendering" rel="nofollow">tiled GPU</a> architectures that would cause the vertex shader to be run many times.</li>
<li>Reduce overdraw by fixing z-sorting. If an entire sky sphere is positioned at [0, 0, 0], it will almost certainly be sorted incorrectly and drawn first every time, even though it should be drawn last. By positioning individual sphere components far away, they should be correctly sorted last.</li>
</ol>
<p dir="auto">Implementing this approach today would require duplicating either the geometry (for different UV coordinates) or the texture (for different offsets) for each piece of the sky. If we could set the offset on the material, each piece would use the same geometry, shader and sampler, only varying the uniform values between draw calls.</p>