KhronosGroup / glTF

glTF – Runtime 3D Asset Delivery
Other
7.16k stars 1.14k forks source link

Texture sampler offset and tile settings #942

Closed stevenvergenz closed 5 years ago

stevenvergenz commented 7 years ago

It would be great if glTF models supported the use of texture atlases, i.e. a single large texture divided into multiple smaller textures. This would be possible if samplers could specify offset and repeat/tile settings in addition to the wrap and filtering modes. Is there any more desire for such a feature?

pjcozzi commented 7 years ago

@stevenvergenz we can consider this post 2.0. In the meantime, you could store these in an extras object property and see how they work out for you. In all of our work, we use texture atlases with explicit texture coordinates so no extra glTF properties are needed.

emackey commented 7 years ago

If you're considering this, you may also want to think about (or at least be aware of) UDIM for texture coordinates. Personally I'm not on the UDIM bandwagon yet, but others are:

Substance Painter: https://support.allegorithmic.com/documentation/display/SPDOC/UDIM

Modo: https://help.thefoundry.co.uk/modo/902/content/help/pages/uving/udim_workflow.html

stevenvergenz commented 7 years ago

@emackey that UDIM thing is an interesting concept, but it sort of does the opposite of what I'm looking for. I'm trying to pack multiple low-res textures for multiple objects (some of which are actually just instances of the same mesh) onto a single larger texture. If I have 50 cubes scattered around, and I wanted to bake lighting, there's no way to bake the lighting for all 50 cubes to a single texture and have the GLTF material point to the right part of the texture for a given object.

emackey commented 7 years ago

@stevenvergenz Ah, so you want multiple cubes that all share a single set of PBR maps, but each one has its own unique baked occlusion map?

To some extent, this case (minus the mesh re-use) can be covered with multiple UV maps. Specifically, exactly two UV maps, one for PBR textures and the other for just the occlusion map. Typically you would UV-unwrap a single instance to create the main UV map. Then you would make a mesh that contained multiple copies of the original, and create a second UV map by UV-unwrapping the mesh with all the copies (without overwriting the first UV map, so each copy still has a set of UV coordinates from the original unwrap). So now, you can assign base color, emission, spec/gloss or metal/rough to the first set of UV coordinates and get that to apply to all copies equally, and you bake an occlusion map using the second set of UV coordinates. As a result, each individual copy will get only a fraction of the surface area on the occlusion UV map, but will have access to the entire main map.

Note that not all implementations fully support multiple UVs yet. I think BabylonJS and ThreeJS both support exactly 2 sets of UVs in glTF 2.0 files. Blender supports multiple named UV maps (but recently I had to look up how to create more than one, it's under the mesh tab and it's not obvious). The draft COLLADA2GLTF converter sadly does not yet support more than one UV map, so I don't have a test model that demonstrates this in action.

stevenvergenz commented 7 years ago

See draft extension AVR_texture_offset_tile: #1015

lexaknyazev commented 5 years ago

Closing, since this has been addressed via KHR_texture_transform extension.