VC model is broken; displays flying boxes.

[donmccurdy]

See: KhronosGroup/COLLADA2GLTF#146

https://cx20.github.io/gltf-test/examples/threejs/index.html?model=VC&scale=0.2

[donmccurdy]

Mentioned in KhronosGroup/glTF#1982 (comment), this model also uses the same textures for base color and occlusion, which must be a mistake in the conversion as well...

[javagl]

This model causes a lot of issues, and analyzing and fixing them is a pain in the back. On top of that, it's not always clear whether a certain issue is caused by the source model, COLLADA2GLTF, or the renderer that is used (although the latter could be checked relatively easily, thanks to cx20's test suite).

But it's still one of my favorite models (if not the favorite model), because it combines nearly all features of glTF (1.0, FWIW). I think it's the only model that has multiple cameras, certainly the only one with animated cameras, fancy material settings (for the windshields), and ... heck, it just looks cool.

I'd be willing to allocate some time to bring this into a shape that is "less buggy".
But ... how successful that could be depends on many unknowns

• I could try to open it in Blender and just hit "export to glTF" with the exporter plugin.
• I could try to re-convert it with the current (latest) state of COLLADA2GLTF
• If one of them works out-of-the box: Yay 💯
  But this is unlikely. So if there are any issues with that:
  • which modifications for the source model may be necessary to "make it work" (and maybe not even how to apply them - I'm not a blender expert...)
  • what causes the possible issues in either the Blender exporter or COLLADA2GLTF, how these could be fixed, and how much effort that would be...

[emackey]

This model shows a dark city with a ton of illuminated windows, yet makes no use of the emissive channel or metallic surfaces. It's a lackluster example of how broken materials were for 3D model files in general before glTF 2.0's core PBR hit the market.

I don't particularly like this model on aesthetic grounds, it looks built with 20-year-old technology. Are there any technical reasons to keep it around?

[emackey]

• Only one texturemap, the base color map.
• Lots of emissive light baked into the base color map.
• Lots of geometric detail suggested in the base color map, such as window edges and steel poles, that are not expressed either as geometry or with normal maps.
• Metallic features are not marked with PBR metal.
• Texture is grainy and noisy up close, with mapping errors scattered about.
• Very low contrast between certain building walls and the city floor. Some structures are almost indistinguishable (see upper-left, an extra building is almost camouflaged there).
• Extremely low-poly, like "runs on my old Voodoo card" kind of low-poly. The nearly-hidden building in the upper-left could be hexagonal, or could be low-poly cylindrical, it's ambiguous.

[cx20]

I also like this model for the same reason as @javagl.
The materials are a bit old-fashioned, but the multiple camera transitions combined with the animations are spectacular.

[donmccurdy]

Here's another attempt at fixing the technical issues (not so much the artistic issues) programmatically:

VC-v2.glb.zip

import { dedup, prune, resample } from "@gltf-transform/lib";

// Previously loaded 'document' with NodeIO or WebIO classes.
const root = document.getRoot();

for (const material of root.listMaterials()) {
	// Occlusion textures on this model are a lie. 
	material.setOcclusionTexture(null);

	// Fix transparency on jet windshield.
	if (material.getName() === '_y4y4y4') {
		material
			.setAlpha(0.5)
			.setAlphaMode('BLEND')
			.setRoughnessFactor(0.0);
	}
}

for (const mesh of root.listMeshes()) {
	const name = mesh.getName();

	// Remove flying boxes.
	if (/^cam|^dum|^box|-box/i.test(name)) {
		mesh.dispose();
	}
}

// Clean up.
await document.transform(
	resample(),
	dedup(),
	prune()
);

That's about as far as I'd want to go in trying to fix it, myself. I tend to agree with Ed that the model is showing its age at this point. We don't have many "whole scenes" in the sample repo at the moment — just VC and Sponza, which has its own issues — so I guess I'm inclined to keep it for now. But I wouldn't be at all sorry to replace it with something a bit more modern someday. 😁

[javagl]

@donmccurdy Do you know from the tip of your head which of these issues are caused by "non-sensical input" or by COLLADA2GLTF? (The point is: Maybe one could do what you did there, like removing the "box" nodes and tweaking some materials, so that the updated DAE can be stored in the repo, and converted to proper glTF with COLLADA2GLTF...)

[donmccurdy]

Just guessing:

1. The boxes have names like "cam-box" and "dummy" suggesting that — in some prior life of this model — they were intentionally used for something.
2. The occlusionTexture entries are likely a conversion bug? Or at least, I can't imagine the same texture was really supposed to act as both AO and base color, and arguably this renders the glTF file invalid since the colorspace can't be both linear and sRGB.
3. The missing transparency on the windshield is anyone's guess..

Fixing the source DAE model sounds like much more work than I'm interested in myself. Doing so would benefit the COLLADA2GLTF project, but as for the sanity of this sample repository, source files in .gltf, .blend (or even .usd) formats would be more future-proof.

[javagl]

Times are changing :-) there once was a reason to keep all the source models in this repo as well.

I'm not sure whether there are any claims (or goals) like ~"The glTFs should be (exactly) the result of applying COLLADA2GLTF to the (DAE) source models". If this is fixed only in the glTF, then the COLLADA source model may be removed (otherwise, it may cause confusion). On the other hand: If there is an issue in COLLADA2GLTF that shows up for this model in particular, the issue should be fixed and the original model could serve as a test case.

I'll try to allocate some time and see what Blender says about this model, with the disclaimers (regarding timeline and success) mentioned above.

(EDIT: If that takes too long, or does not lead anywhere, there's still the option to 1. just update the glTF with the gltf-transform'ed version and deleting the source, and 2. opening an issue in COLLADA2GLTF to investigate that further)

[emackey]

I've always found it odd: We talk about COLLADA being an interchange format, and glTF being a transmission/delivery format, and the two formats have different design goals with different information encoded in each. Why then are we obsessed with having an automated utility that converts one to the other, untouched by human hands? The Venn Diagram of COLLADA contents and glTF contents has some overlap for basic geometry, but there are things on the COLLADA side that are guaranteed to be lost, and things on the glTF side (including all of PBR) that will never be created by such a process.

Many sample models in this repo display and test draft extensions, or recently ratified extensions, for which automated exporters are not available. The sourceModels folder is more of a collection of raw assets that were used in the creation of a glTF, but I think there cannot be a hard requirement for an automated conversion from raw source assets to finished glTF. For example, it's quite helpful to me to keep the Blender projects and GIMP save files around for things like TransmissionRoughnessTest, even though Blender and GIMP cannot reproduce this model by fully automated means.

In the early development of COLLADA2GLTF, we were re-running automated conversion on a routine basis, as both the converter and the 2.0 spec itself were undergoing massive changes at the time (before 2.0 was ratified). Those days are gone, the 2.0 core spec is established and adopted, and the converter is no longer under active development. We shouldn't still be expecting some automated process to get from a raw source interchange format to a final deliverable art asset. And it can still be helpful to keep the raw interchange format around as reference, just drop the expectation of automated conversion.

[emackey]

Long story short, I would keep the COLLADA file, and put a copy of Don's code snippet in a text file alongside it.

[cx20]

The missing transparency on the windshield is anyone's guess..

BTW, I found the original display results in the asset store. Indeed, it seems that the windshield of the original model was transparent.

https://3drt.com/store/environments/virtual-city-pack.html