Issue 1:
Description of the problem

Hi there. This is the error message:

[.CommandBufferContext]RENDER WARNING: there is no texture bound to the unit 1

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])

This is my test code for the issue:

test link for [r75]

test link for [dev]

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.

Three.js version

Dev

r75

...

Browser

All of them

Chrome

Firefox

Internet Explorer

OS

All of them

Windows

Linux

Android

IOS

Hardware Requirements

Hardware isn't relevant.

Issue 2:
Seems like I'm finally starting to experiment with something that I've been thinking for a long time.

The problem

The current Geometry structure is, albeit user-friendly, convoluted and unperformant. That structure was designed before WebGL even existed and it has been patched along the way.

BufferGeometry was created as a response to this. However, BufferGeometry has the opposite problem, it's not user-friendly. I don't think a "normal" user needs to know what attributes are.

Every time I see a three.js based project running on WebGL on mobile I hope (fear) the persons behind it didn't use Geometry.

The solution

I spent a long while trying to think how to make BufferGeometry more user friendly, but I couldn't see a way of doing that without sacrificing its flexibility so eventually I decided to keep BufferGeometry as it is. I spent some time during the last cycle making Projector (CanvasRenderer, SoftwareRenderer, SVGRenderer, ...) support the structure instead.

https://github.com/mrdoob/three.js/blob/dev/src/core/Projector.js#L307-L342

The intention now is to go with Geometry2, which eventually would replace Geometry and break backwards compatibility, although I wonder if people modify geometry much or not...

The idea of Geometry2 is to have everything in flat arrays: vertices, normals, uvs and colors ready to be submitted to the GPU (on the WebGL side).

https://github.com/mrdoob/three.js/blob/dev/src/core/Geometry2.js

However, that's not very user-friendly... I experimented with a similar class some months ago that had some "interfaces" to help the user:

https://github.com/mrdoob/three.js/blob/dev/examples/js/core/TypedGeometry.js

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:

geometry.face( 10 ).vertex( 1 ).x = 10;

However, this would only be for the user. Generators and loaders would fill the arrays directly. Here's how PlaneGeometry2 looks like:

https://github.com/mrdoob/three.js/blob/dev/src/extras/geometries/PlaneGeometry2.js

As a side not, performance-wise, I've noticed that where PlaneGeometry was created in ~6ms, PlaneGeometry2 generates in ~0.3ms.

On the Projector side, the code is looking pretty simple so far:

https://github.com/mrdoob/three.js/blob/dev/src/core/Projector.js#L343-L358

To index or not to index

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 WebGLRenderer is the fact that WebGL limits ELEMENT_ARRAY_BUFFER (indices) to Uint16Array (without extensions). This means that, internally, WebGLRenderer has to split your geometry in chunks and well... I rather not explain how painful this is.

So, even if indexed geometries save on GPU bandwidth, I don't think the complexity it creates is worth it. Geometry2 won't support indices (Let me know if I'm missing something here).

However, BufferGeometry will still be in place, so if someone wants to construct their custom indexed geometry they will still have a way to do it.

Outcome

In theory, generators and loaders will speed up ~10x. Projects will consume less memory (single Float32Arrays vs tons of Vector2/Vector3s). And, both Projector and WebGLRenderer will get much simpler.