Can someone tell me if it’s possible to use multiple map channels in babylon/webgl?
We’re working in 3ds max, at the moment we’re looking into baking our textures so that the visuals can look like the renders we make. Therefore we’re using some tools and plugins.
However they rely on multiple map channels to keep the original textures at channel 1, and put the baked & unwrapped textures at a higher (free) map channel slot.
When using this workflow we noticed some issues, which could be caused by the lack of multiple map channels in webgl/babylon, can someone let me know how this works in babylon?
I think @PatrickRyan is your best bet for cogent, informed answers about art workflows. He’s super busy at the moment, so it may take him some time to get back to you, but he’s by far the most knowledgeable person to help with a question like this.
@Pieter_van_Stee, both Babylon.js and the glTF 2.0 specification both allow for multiple texture coordinate sets, in Max called map channels, specifically for things like baked light/shadow maps, or AO maps for materials using tiling textures. In Babylon.js, we set the texture coordinates on the texture using
Texture.coordinatesIndex. For glTF, they are set with the texCoord property on the texture properties of a material:
Hello @Pieter_van_Stee just checking in, was your question answered?
Hi @PatrickRyan thanks for replying to my question, have been busy for a while and could only check back at this time.
Anyway that’s really reassuring to know multiple texture channels are supported, as we had some issues with that when exporting from 3ds Max. I will definitely look further into this, but your scheme is already clarifying a lot for me.
Just wondering so TEXCOORD_1: 5 means SKYBOX_MODE?
How is the mapping described when we have our textures unwrapped in max?
@Pieter_van_Stee to answer your question about TEXCOORD_1: 5 in the sample image of the construction of glTF files, it’s not quite what you are referring to. In this case, the sample glTF shows that it has two UV sets on the mesh in question. The value after key TEXCOORD_1 just refers to an accessor later in the glTF file. It’s basically an address for more information about that particular UV set.
For example, this is a sample glTF file I have, it only has one UV set, but for illustration purposes it will work.
This specific glTF file has three meshes in it, so each mesh has a pointer to the accessor information on the specific UV set in question. Elsewhere in the file, we have the rest of the parameters for this mesh’s first UV set:
This is the data in the accessors array sitting at index 7 (indices start at 0, so it’s the eight set in accessors). So the number after any of the texCoord keys is just a reference to a location in the accessors array. As you can see from the image above there is a lot of data that is referencing other places in the glTF file, and those are connected by assigning an index value of the appropriate array located elsewhere in the file.
In terms of the base glTF file, there is nothing that describes what any particular UV set is used for. There are just basic connections between the materials, textures, and mesh UVs telling the renderer how to display the file.
When you mention “SKYBOX_MODE” I’m not entirely certain what you are referencing. In Babylon.js a skybox is a specific feature of the engine that expects 6 individual images to form a cube map that has a specific naming convention to help with creation. But if you mean “environment lighting” or “image-based lighting”, there is a specific glTF IBL extension that allows you to save IBL images into a glTF, but the challenge is that the engine rendering the glTF needs to support it. Babylon.js does support this extension, but if you are sending your glTF files out to be used in different viewers (as in an e-commerce solution) you need to check that the viewers have implemented this extension. Typically, it’s best to stick to the base glTF 2.0 specification if you expect your models to be rendered in various viewers.