GLTF2 Exporter

[fernandojsg]

This is a WIP GLTF v2 Exporter.

The code is not clean yet but I wanted to have a place to discuss this implementation from the very beginning so I hope we could end up with a fully featured exporter.

Features / TO-DO:

• Include userData in extras?

• Scenes

  • Support for multiple scenes

• Nodes

  • Meshes
    • Primitive mode:
      • TRIANGLES
      • TRIANGLE_STRIP
      • TRIANGLE_SPAN
      • POINTS
      • LINES
      • LINE_STRIP
      • LINE_LOOP
    • Geometry types:
      • BufferGeometry
      • Geometry
    • Primitive attributes:
      • POSITION
      • NORMAL
      • TEXCOORD_0
      • TEXCOORD_1
      • COLOR_0
      • JOINTS_0
      • WEIGHTS_0
      • TANGENT
  • Light: Need KHR_Light extension
  • Camera
  • Skin

• Materials:

  • Ignore if default material is being used
  • Export as lines if material.wireframe === true
  • pbrMetallicRoughness for MeshStandardMaterial
    • Attributes:
      • baseColorFactor
      • metallicFactor
      • roughnessFactor
      • baseColorTexture: It's supported (material.map) but the texCoord is always set to 0.
    • doubleSided

• Samplers

• Images:

  • uri using map.image.src
  • uri base64
  • bufferView
  • Deal with flipY images

• Accessors

  • Use the same bufferView for the same componentType instead of creating a new one for each attribute
  • Support sparse?
  • Attributes:
    • bufferView
    • byteOffset: Currently it's using 0 always as I'm creating a new bufferView for each accessor.
    • componentType
    • count
    • max
    • min
    • type:
      • SCALAR
      • VEC2
      • VEC3
      • VEC4

• BufferViews: Currently I'm creating a new bufferView for each Accessor, this should be fixed to use just one for these attributes that share the same componentType

  • Attributes:
    • buffer
    • byteOffset
    • byteLength
    • byteStride
    • target

• Buffers: Currently I'm saving everything to a single buffer so it will be just one entry in the buffers array.

  • byteLength
  • uri

Output from the current example scene: https://pastebin.com/s8Hd1AWZ

NOTE: I've added a simple example (gltf_exporter.html) just to have something quick to test while developing.

/cc @donmccurdy @takahirox

[fernandojsg]

One of the issues I've found with the images is that GLTF lacks of support for flipY. If we're embedding the textures directly on the file we could flip them ourselves, but what if we're using url?

[fernandojsg]

In MeshStandardMaterial we have metalnessMap and roughtnessMap which one should we use for metallicRoughnessTexture? From the loader I see it's sharing the same value for both maps, but what about the opposite?
https:/mrdoob/three.js/blob/dev/examples/js/loaders/GLTF2Loader.js#L2140-L2146

[donmccurdy]

One of the issues I've found with the images is that GLTF lacks of support for flipY. If we're embedding the textures directly on the file we could flip them ourselves, but what if we're using url?

is OBJExporter geometry-only? I guess this hasn't come up yet. Maybe support for flipY could be added to a texture-related extension, but I would lean toward embedding the image data if it's manageable (see below).

In MeshStandardMaterial we have metalnessMap and roughtnessMap which one should we use for metallicRoughnessTexture? From the loader I see it's sharing the same value for both maps, but what about the opposite?

Roughness and metalness must be packed together in a single texture for glTF. Also occlusionTexture could point to that same texture, but that is not required.

[mrdoob]

What's examples/321103__nsstudios__blip1.wav for? 🤔

[mrdoob]

Include userData in extras?

Yep!

[mrdoob]

Geometry

I think for the time I would just do geometry.toBufferGeometry().

[donmccurdy]

KHR_Material_common

^I would omit this. Most of the extension probably won't be added to glTF 2.0, just a slimmed down Phong-only version, which isn't finished yet.

[fernandojsg]

@mrdoob

What's examples/321103__nsstudios__blip1.wav for? 🤔

My fault 👼 I don't know what I was doing there :)

Include userData in extras?

Right now you can store everything you want in userData right? So how to store it? Serializing the json? base64? just hope that userdata is just a JSON or array and just leave it like that?

geometry.toBufferGeometry()

Cool, I'll give it a try thanks.

[fernandojsg]

@donmccurdy

Roughness and metalness must be packed together in a single texture for glTF. Also occlusionTexture could point to that same texture, but that is not required.

Ok, I've just read that we could have roughtness in G, metalness in B and occlusion in R.

^I would omit this. Most of the extension probably won't be added to glTF 2.0, just a slimmed down Phong-only version, which isn't finished yet.

So what we do when the material is not MeshStandardMaterial ? just store a pbr filling the attributes we could match?

[fernandojsg]

@mrdoob I can't find toBufferGeometry is still not implemented?

[fernandojsg]

my fault, I believe you were referring to BufferGeometry.fromGeometry

[fernandojsg]

GLTF doesn't have support for the material.flatShading = true property so the exporter will save the normals as they're on the geometry (smooth by vertex) and the loader will just use them showing smooth shading instead of flat.
I believe the best way to get this working is to just compute normals per face instead of per vertex when exporting if flatShading = true. This means that we should duplicate vertices as each one would as many normals as face it's connected to.
What do you think @mrdoob ?

[WestLangley]

I have noticed that the glTF examples are over-bright. This should be something like:

scene1.add( new THREE.AmbientLight( 0xffffff, 0.2 ) );

[fernandojsg]

Thanks, done!

[WestLangley]

This is OK. Same as:

var light = new THREE.DirectionalLight( 0xffffff, 1 );

[WestLangley]

Just so everyone is on the same page, with the exception of MeshLambertMaterial, vertex normals are neither used, nor required, when rendering with flat shading.

[fernandojsg]

@WestLangley yes, but as GLTF doesn't allow us to define a flat shading material (AFAIK, /cc @donmccurdy) the only way we could differentiate between flat and smooth is by processing the vertex shader before exporting them

[fernandojsg]

The exporter is already fully functional, the most important parts that are missing in this PR:

• Normals for flat shading
• Textures processing:
  • Convert images to base64
  • Flip images if flipY=true
  • Merge roughnessTexture + metalnessTexture + aoTexture

Here is the current example exported and imported on @donmccurdy 's viewer (note that ambient light is different too)

I believe it's better to review the current features so we could keep evolving it in smaller feature-based PRs that would be easier to review than growing this one too much.

[donmccurdy]

@fernandojsg If normals are omitted, glTF requires viewers to display the mesh with flat shading (source).

[mrdoob]

I believe the best way to get this working is to just compute normals per face instead of per vertex when exporting if flatShading = true. This means that we should duplicate vertices as each one would as many normals as face it's connected to.

Sounds a bit too complicated. I would ignore this for now.

[mrdoob]

The exporter is already fully functional, the most important parts that are missing in this PR:

Do you want to merge this in the meantime?

[fernandojsg]

@donmccurdy cool, I didn't know that, thanks! So a first approach could be to just delete de normals for the mesh with flatShading=true.
@mrdoob yes please, so we could keep working on the details separately without growing the PR so much.

[mrdoob]

Many thanks!