<h5 dir="auto">Description of the problem</h5>
<p dir="auto">Hi there. This is the error message:</p>
<blockquote>
<p dir="auto">[.CommandBufferContext]RENDER WARNING: there is no texture bound to the unit 1</p>
</blockquote>
<p dir="auto">I try to ignore these warnings, but sometimes (more than 50% time in my 3D Game) it will stop loading textures. It drove me crazy for a whole day and finally found it was caused by the latest Chrome update [Version 50.0.2661.75 m]. (Chrome was updated from [Version 49.0.2623.110 m])</p>
<p dir="auto">This is my test code for the issue:<br>
<a href="http://rendxx.github.io/RendxxGitHub/Test/LightIssue/test-master.html" rel="nofollow">test link for [r75]</a><br>
<a href="http://rendxx.github.io/RendxxGitHub/Test/LightIssue/test-dev.html" rel="nofollow">test link for [dev]</a></p>
<p dir="auto">It is a simple environment to reproduce the issue. It looks fine in this example, but if the scene is complex enough, some textures will be missing.</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" checked=""> Dev</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox" checked=""> r75</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> ...</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" checked=""> Windows</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> 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</h5>
<p dir="auto">Hardware isn't relevant.</p>
<p dir="auto">Seems like I'm finally starting to experiment with something that I've been thinking for a long time.</p>
<p dir="auto"><strong>The problem</strong></p>
<p dir="auto">The current <code class="notranslate">Geometry</code> structure is, albeit user-friendly, convoluted and unperformant. That structure was designed before WebGL even existed and it has been patched along the way.</p>
<p dir="auto"><code class="notranslate">BufferGeometry</code> was created as a response to this. However, <code class="notranslate">BufferGeometry</code> has the opposite problem, it's not user-friendly. I don't think a "normal" user needs to know what attributes are.</p>
<p dir="auto">Every time I see a three.js based project running on WebGL on mobile I hope (fear) the persons behind it didn't use <code class="notranslate">Geometry</code>.</p>
<p dir="auto"><strong>The solution</strong></p>
<p dir="auto">I spent a long while trying to think how to make <code class="notranslate">BufferGeometry</code> more user friendly, but I couldn't see a way of doing that without sacrificing its flexibility so eventually I decided to keep <code class="notranslate">BufferGeometry</code> as it is. I spent some time during the last cycle making <code class="notranslate">Projector</code> (<code class="notranslate">CanvasRenderer</code>, <code class="notranslate">SoftwareRenderer</code>, <code class="notranslate">SVGRenderer</code>, ...) support the structure instead.</p>
<p dir="auto"><a href="https://github.com/mrdoob/three.js/blob/dev/src/core/Projector.js#L307-L342">https://github.com/mrdoob/three.js/blob/dev/src/core/Projector.js#L307-L342</a></p>
<p dir="auto">The intention now is to go with <code class="notranslate">Geometry2</code>, which eventually would replace <code class="notranslate">Geometry</code> and break backwards compatibility, although I wonder if people modify geometry much or not...</p>
<p dir="auto">The idea of <code class="notranslate">Geometry2</code> is to have everything in flat arrays: <code class="notranslate">vertices</code>, <code class="notranslate">normals</code>, <code class="notranslate">uvs</code> and <code class="notranslate">colors</code> ready to be submitted to the GPU (on the WebGL side).</p>
<p dir="auto"><a href="https://github.com/mrdoob/three.js/blob/dev/src/core/Geometry2.js">https://github.com/mrdoob/three.js/blob/dev/src/core/Geometry2.js</a></p>
<p dir="auto">However, that's not very user-friendly... I experimented with a similar class some months ago that had some "interfaces" to help the user:</p>
<p dir="auto"><a href="https://github.com/mrdoob/three.js/blob/dev/examples/js/core/TypedGeometry.js">https://github.com/mrdoob/three.js/blob/dev/examples/js/core/TypedGeometry.js</a></p>
<p dir="auto">All that getters/setters black magic basically allows the user to modify the geometry without having to know that they're just modifying a blob of numbers. The API looked like this:</p>
<div class="highlight highlight-source-js notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="geometry.face( 10 ).vertex( 1 ).x = 10;"><pre class="notranslate"><span class="pl-s1">geometry</span><span class="pl-kos">.</span><span class="pl-en">face</span><span class="pl-kos">(</span> <span class="pl-c1">10</span> <span class="pl-kos">)</span><span class="pl-kos">.</span><span class="pl-en">vertex</span><span class="pl-kos">(</span> <span class="pl-c1">1</span> <span class="pl-kos">)</span><span class="pl-kos">.</span><span class="pl-c1">x</span> <span class="pl-c1">=</span> <span class="pl-c1">10</span><span class="pl-kos">;</span></pre></div>
<p dir="auto">However, this would only be for the user. Generators and loaders would fill the arrays directly. Here's how <code class="notranslate">PlaneGeometry2</code> looks like:</p>
<p dir="auto"><a href="https://github.com/mrdoob/three.js/blob/dev/src/extras/geometries/PlaneGeometry2.js">https://github.com/mrdoob/three.js/blob/dev/src/extras/geometries/PlaneGeometry2.js</a></p>
<p dir="auto">As a side not, performance-wise, I've noticed that where <code class="notranslate">PlaneGeometry</code> was created in ~6ms, <code class="notranslate">PlaneGeometry2</code> generates in ~0.3ms.</p>
<p dir="auto">On the <code class="notranslate">Projector</code> side, the code is looking pretty simple so far:</p>
<p dir="auto"><a href="https://github.com/mrdoob/three.js/blob/dev/src/core/Projector.js#L343-L358">https://github.com/mrdoob/three.js/blob/dev/src/core/Projector.js#L343-L358</a></p>
<p dir="auto"><strong>To index or not to index</strong></p>
<p dir="auto">This is another topic that has troubled me for years and I think I want to bet to favour non-indexed geometries this time around. Part of the current over complexity in <code class="notranslate">WebGLRenderer</code> is the fact that WebGL limits <code class="notranslate">ELEMENT_ARRAY_BUFFER</code> (indices) to <code class="notranslate">Uint16Array</code> (without extensions). This means that, internally, <code class="notranslate">WebGLRenderer</code> has to split your geometry in chunks and well... I rather not explain how painful this is.</p>
<p dir="auto">So, even if indexed geometries save on GPU bandwidth, I don't think the complexity it creates is worth it. <code class="notranslate">Geometry2</code> won't support indices (Let me know if I'm missing something here).</p>
<p dir="auto">However, <code class="notranslate">BufferGeometry</code> will still be in place, so if someone wants to construct their custom indexed geometry they will still have a way to do it.</p>
<p dir="auto"><strong>Outcome</strong></p>
<p dir="auto">In theory, generators and loaders will speed up ~10x. Projects will consume less memory (single <code class="notranslate">Float32Array</code>s vs tons of <code class="notranslate">Vector2</code>/<code class="notranslate">Vector3</code>s). And, both <code class="notranslate">Projector</code> and <code class="notranslate">WebGLRenderer</code> will get much simpler.</p>