gltf 2.0 models rendering black in babylon.js and cesium viewers when normals are not specified about gltf-vscode HOT 10 CLOSED

@bghgary @pjcozzi Are viewers expected to calculate missing normals? Does the spec explicitly state that normals are the responsibility of the exporter?

@kcoley Part of the "spirit of glTF" is that we try to move all processing burdens to the exporters and glTF creators, and keep those burdens off the viewers and runtime engines. The model is intended to be in a ready-to-render state when it arrives, to the extent reasonable, because the runtime may be on a battery-operated mobile device without a lot of spare cycles for calculating normals that could have been supplied. So my suggestion would be, always supply the normals, but I've asked some other members of the working group if there's a more official statement on this.

from gltf-vscode.

@emackey Per implementation note, https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#meshes

Implementation note: When normals are not specified, client implementations should calculate flat normals.

from gltf-vscode.

@kcoley Thanks for writing this up. I lost track of this a bit, but the Cesium engine now has an issue open to fix it here: CesiumGS/cesium#5838. I don't know if the BabylonJS folks have a corresponding issue.

from gltf-vscode.

BabylonJS folks have a corresponding issue.

BabylonJS has supported normal generation for some time now, though it is currently broken right now. How often do you update the BabylonJS bits? It might make sense to point to the latest BabylonJS on the CDN, perhaps even use the preview links.

from gltf-vscode.

Ah, I may just need a Babylon refresh, once the issue is resolved.

How often do you update the BabylonJS bits?

Not on any schedule, which is a problem for all the engines I guess. I've avoided adding CDN links because I need this plugin to work on a disconnected network with no CDN access. I suppose there should be a recurring task to update each of the engines at some frequency. I wonder if I could convince a bot to file those PRs for me, hmmm.

though it is currently broken right now

Do you have an issue handy for this, that we could link to from here? Thanks @bghgary!

from gltf-vscode.

No, unfortunately, we don't have an issue on GitHub for this. Do we need one?

from gltf-vscode.

No not for my sake, thanks.

from gltf-vscode.

Normals issue in BabylonJS is now fixed.

from gltf-vscode.

This issue looks resolved in the current version of the extension.

from gltf-vscode.

The issue should be resolved for Babylon with the next published release of the extension (coming soon!). Cesium has a separate issue to track this, CesiumGS/cesium#5838.

I am going to close this since it's not a bug in this VSCode extension itself. Thanks everyone!

from gltf-vscode.