Three.js: Applying UVs by Polygon-Vertex vs. by Direct-Vertex.

[Kyle-Larson]

(* This section is for bug reports and feature requests only. This is NOT a help site. Do not ask help questions here. If you need help, please use stackoverflow. *)

Description of the problem

As far as I understand, UVs cannot currently be applied by polygon-vertex and must be applied directly to the vertex. This creates issues with UV-unwrapping objects because the object must be unwrapped into one 2-D mesh rather than being able to split it into multiple parts, and the seams must have duplicated vertices to avoid wrapping issues at the seams.

I'm not 100% sure if it's possible to use two separate buffers for vertices and UVs and use separate indices to both in the Geometry Face, or if we are limited to only using one index for every buffer. It's not as big of an issue for things like normals, but it becomes an issue with UVs. If it's not possible to generate geometry buffers like so, then the loaders need to duplicate the vertices if there is data applied per face rather than per vertex, which is gonna be a large and annoying change, but a necessary one if there is no other option. Wanted to open a dialogue about this and determine the best way to approach this issue.

Three.js version

• [x] Dev
• [ ] r82
• [ ] ...

Browser

• [x] All of them
• [ ] Chrome
• [ ] Firefox
• [ ] Internet Explorer

OS

• [x] All of them
• [ ] Windows
• [ ] Linux
• [ ] Android
• [ ] IOS

Hardware Requirements (graphics card, VR Device, ...)

[WestLangley]

Geometry supports per-face UVs.

BufferGeometry supports only one UV per vertex, so on a seam with discontinuous UVs, the vertex will have to be duplicated.

The loaders are being modified to return BufferGeometry.

Wanted to open a dialogue about this and determine the best way to approach this issue.

Can you please explain your use case, and what, exactly, is the problem you are facing?

[Kyle-Larson]

Yes, so in our project we're currently in the process of UV-unwrapping and texturing our models for use in a three.js engine (which is why I've been pretty involved in the FBXLoader.js file). When we unwrap the geometry, obviously there are seams that are present. When the FBX with the UVs gets exported, Maya labels UVs on a per face-vertex basis. This makes sense so that you don't interpolate all the colors in a texture between seams. But since the FBXLoader currently only stores one UV per vertex, this means that one of the two UVs at a seam is chosen, and it causes one of the faces sharing that seam to have to interpolate colors between the two UVs. The best example can actually be seen with the three.js fbx example:

The yellow behind the neck is actually part of the leg texture. This is because we can't sow seams together because each vertex is only allowed one UV, so the loader interpolates colors between the top of the back and the bottom of the neck, which happens to contain the leg UV

So in order to avoid this, we need UVs to be stored on a per-face per-vertex structure, rather than only on a per-vertex. But if the loaders are only generating BufferGeometry which doesn't allow for this structure, then we can't avoid this from happening without duplicating vertices.

[WestLangley]

Thanks for the additional detail. I think everything you say is true.

It appears in the example that FBXLoader is instantiating a temporary BufferGeometry and converting it to Geometry -- which is then, of course, converted back to BufferGeometry by the renderer.

It seems there is room for improvement in that regard.

[Kyle-Larson]

So does it make sense to make the FBXLoader skip creating a BufferGeometry and just create Geometry with the Per-Face data being applied per face, since the renderer will convert it back into a BufferGeometry? I've heard talks of just directly using BufferGeometry and avoiding use of Geometry, but I wasn't sure what the verdict on that was.

[WestLangley]

It makes sense to skip Geometry and return BufferGeometry. The loader should be considerably faster on large datasets, for one thing.

You can return indexed, or non-indexed, BufferGeometry -- your choice.

[Kyle-Larson]

You can return indexed, or non-indexed, BufferGeometry -- your choice.

So duplicate vertices in the buffer that have different UVs depending on the face? I'll probably have to re-do a lot of the logic behind indexing the buffer and assigning UVs / Normals to the geometry, but it's doable.

And that brings up the question of what to do about Vertex normals. We can either blend them for each vertex, choose only one of the normals, or duplicate the vertex if it has different normals per face. If we duplicate, we're likely to copy vertices to the point of having double or triple the number of vertices, in which case we might be better off just going non-indexed.

[WestLangley]

So duplicate vertices in the buffer that have different UVs depending on the face?

You have to duplicate the vertices in the buffer that differ on _any_ attribute, not just UVs.

might be better off just going non-indexed

Yes, that should get you to working code more quickly.

[makc]

It makes sense to skip Geometry and return BufferGeometry. The loader should be considerably faster on large datasets, for one thing.

for another thing, you are forcing each and every loader to implement the same logic that used to be handled by old geometry.

[Kyle-Larson]

for another thing, you are forcing each and every loader to implement the same logic that used to be handled by old geometry.

Yeah, makes sense. So I'll work on updating the FBX loader to exclusively use BufferGeometry non-indexed so that we can get per-face UVs, normals, etc.

[makc]

I was addressing that to @WestLangley and the team. they are pushing too hard for buffergeometry, imho, where they maybe could just refactor geometry better.

[Kyle-Larson]

they maybe could just refactor geometry better.

I agree on the idea that logic for converting Geometry into BufferGeometry that would be needed to be implemented by every loader should be extracted and made into its own utility or something. Either via refactoring Geometry itself or just creating some sort of geometry utility, but as long as the user doesn't want to directly manipulate the faces of the geometry after loading the geometry, it makes sense to return BufferGeometry from the loaders and not pay conversion costs outside of the loaders.

[Kyle-Larson]

Issue resolved with new FBX loader ( #10588 ).