Add PointsLinesTrianglesTest

[lexaknyazev]

This test shows how different primitive modes are rendered depending on the normals and vertex colors presence.

[lexaknyazev]

The spec currently does not define some of the cases present in this test, so it's expected that engines behave differently. The goal of this PR is to agree on the preferred result and to update the spec.

Positions

When vertex normals are not defined, an implementation should generate flat normals. This is quite straightforward for triangles (although Cesium and Filament haven't implemented that yet) but unfeasible for points and lines. There are three potential options:

1. Treat points and lines as if they use KHR_materials_unlit, i.e., simply use the base color multiplied by vertex colors. That's what three.js does.
2. Same but also take in account emissive component. That's what the Sample-Viewer, Babylon, Cesium, and Filament do, however Filament does not render lines at all.
3. Treat points and lines as 1px spheres and cylinders respectively, compute proper normals and apply all lighting equations. Does not seem to be supported anywhere.

Positions & Normals

When vertex normals are defined, implementations have all the information to apply lighting as usual. The Sample-Viewer follows this; three.js, Babylon, and Filament ignore everything except the base and emissive components.

/cc @donmccurdy @bghgary @emackey @elalish

[cx20]

BTW, it may be a matter of taste, but I prefer the model to be in the center of the Scene, as in the TransmissionTest model.

[lexaknyazev]

@cx20
It's a draft. Once we agree on the rendering, I'll add a readme and center the objects. Still, many engines rescale and recenter everything to fit on screen themselves.

[cx20]

I added this model to gltf-test as an experiment. The results at the moment are as follows.

Edit 2021.09.02
The link destination of Babylon.js was localhost, so I fixed it. The linked version is the one at the time of testing.

[lexaknyazev]

What version of the Sample-Viewer is used there? The one hosted at https://github.khronos.org/glTF-Sample-Viewer-Release/ shows a different result.

[cx20]

What version of the Sample-Viewer is used there? The one hosted at https://github.khronos.org/glTF-Sample-Viewer-Release/ shows a different result.

I tried the same version of viewer as above.
I changed some options. I turned off Blur and set papermill.hdr as IBL.

Environment : Windows 10 + GeForce RTX 2060 + Chrome 92

[lexaknyazev]

This looks strange. Here's what I see in the Sample-Viewer:

Chrome 92 & Firefox 91, macOS 11.5.2

[lexaknyazev]

Can confirm that some engines on Windows do not render points or lines at all (or show some geometry mess).

[cx20]

I changed Chrome's WebGL backend to OpenGL and found that the model was visible.

[lexaknyazev]

Filed KhronosGroup/glTF-Sample-Viewer#347.

[sebavan]

@cx20 here is what I see in the Babylon sandbox with our latest version

which sounds correct ?

[lexaknyazev]

@sebavan
Yes, the materials look correct according to our recent review of the relevant spec section.

One nit: why are the reflections in the points-based spheres (column 4) noticeably more sharp than in others?

[cx20]

@sebavan I tested it again with the latest version of Babylon.js. As you say, the latest version seems to be improved.

PointsLinesTrianglesTest.gltf result:

[sebavan]

@lexaknyazev you have eagle eyes :-) This comes from the specular antialiasing as the derivatives might not be computed in the same way with the rasterizer (flat point vs soft normals) I would suspect.

Thanks a lot @cx20 for the double check :-)

[emackey]

I like this model, but is it obsolete now? We have this one merged already:

https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0/MeshPrimitiveModes

[javagl]

The MeshPrimitiveModes is a very simple, test - no materials, no vertex colors, no normals. So the sample here definitely covers things that are not covered elsewhere (and the different mesh primitive modes are are somewhat secondary, but important for completeness). I'd say it's not obsolete, but ... it has been a 'draft' for quite a while now...

[lexaknyazev]

@emackey @javagl
This model specifically targets handling missing/present vertex normals with different primitive modes. It has a few minor issues:

• Missing readme
• Incorrect scene center
• Maybe needs a more specific name?

[javagl]

The README could probably be filled with some information from this thread.
The scene center ... could probably be twiddled manually (sounds like a translation on the root node could be enough)
The name... well, ... "naming things". It's a very specific, technical test model, and it could be hard to squeeze this specificity into a name. Maybe PrimitiveModeNormalsTest or so...?

I'm not sooo deeply involved in some parts here, but...

1. Treat points and lines as if they use KHR_materials_unlit [...]
2. Same but also take in account emissive component.

Looking at the images in an earlier comment (and the emissive values of [0,0.1,0.1]) this is a very subtle difference visually. If this is one dimension that determines whether a rendered result is "right" or "wrong" (according to the to-be-updated spec), then it might make sense to set something as clear as [0,1,0] and [1,0,0] as the base- and emissive colors, to immediately see whether it was taken into account or not.