Moving a mesh between tools is only part of moving an object. A metal surface can arrive as gray plastic. A rough painted surface can become glossy. The vertices survived, but a large part of the object's identity did not.
The glTF 2.0 specification released in June addresses this with a shared physically based material model. The important change is the level of description. Instead of relying on a particular GLSL shader as the material definition, an asset can provide parameters that different rendering systems know how to interpret.
Think of a small painted metal lamp. Its geometry defines the shape. Texture coordinates decide where images attach. A base-color texture describes spatial variation in color, while metallic and roughness values communicate other aspects of surface response. A normal map can add small variations in apparent surface direction without adding the same detail to the mesh.
These values still need a renderer. They are a contract about meaning, not a precomputed photograph. A viewer using Direct3D and a viewer using WebGL can implement that contract through different shader programs. This is what makes the description portable across graphics APIs.
The shared description travels with the asset. Lighting and renderer choices still influence the final image.
It does not guarantee identical screenshots. Place the lamp in a dark room and polished metal may appear almost black. Give it a bright environment to reflect and it looks entirely different. Exposure, display transforms, sampling and implementation quality also affect the result. A common material language removes one source of ambiguity while leaving the lighting and viewing problem intact.
This suggests a sensible way to investigate an export problem. Start with the asset data: did the intended textures arrive, and do their channels contain the expected information? Then examine how the viewer interprets those values. Only after that compare lighting, environment and display settings. Otherwise it is easy to compensate for a missing texture by changing lights and accidentally create a scene that works in only one viewer.
For delivery, the distinction between an authoring document and a runtime asset matters too. A modeling project may contain construction history, procedural nodes and editor-specific controls. A compact delivery format should carry what the application needs to reproduce the result, with predictable relationships between scene nodes, geometry, images and animation. It doesn't need to recreate every decision that led there.
I like glTF's emphasis on that boundary. A web viewer shouldn't have to understand the private language of every content tool. A content tool shouldn't have to generate a unique asset for every graphics API. A shared description gives both sides something concrete to implement and validate.
The material model is therefore more than a convenient set of sliders. It makes an object easier to discuss across tools. When a surface looks wrong, there is a common vocabulary for asking whether the data, the interpretation or the environment caused the difference.