Integrate latest AsciiDoc updates

[lexaknyazev]

• Clarified Points and Lines rendering.
• More detailed explanation of sampler wrapping modes.
• Reordered and expanded skinning section.
• Added examples of non-ASCII paths.
• Removed the reference to the external extension document (it will be replaced anyway).
• Added references to GL-originated integer enum values.
• Minor tweaks, language and typography fixes.

[bghgary]

Reviewed the skinning section.

[emackey]

I think this is as clear as we can be on points & lines without introducing new properties.

[lexaknyazev]

@emackey

I think this is as clear as we can be on points & lines without introducing new properties.

Just in case, do you approve all other edits?

[emackey]

Yes, everything in this PR looks good to me.

[emackey]

One other question, and I hope this isn't too off-topic here, but: Can TEXCOORD_0 be used as a morph target attribute? I'm pretty sure no one implements this, but is it forbidden by spec? I know of cases where it would be useful, particularly in scientific vis.

[lexaknyazev]

Can TEXCOORD_0 be used as a morph target attribute?

The spec says:

Client implementations SHOULD support at least three attributes -- POSITION, NORMAL, and TANGENT -- for morphing.

I think it's safe to say that it does not forbid such usage given that later the spec mentions morphing custom attributes. So let's mention TEXCOORD_n and COLOR_n explicitly.

WDYT?

[emackey]

I think it's safe to say that it does not forbid such usage given that later the spec mentions morphing custom attributes. So let's mention TEXCOORD_n and COLOR_n explicitly.

@bghgary or @donmccurdy Do you know if this would cause heartache for Babylon or ThreeJS?

[lexaknyazev]

The missing spec part is the entries in the table with allowed accessor types. A similar fix is also needed for the KHR_mesh_quantization extension that extends the table.

Despite all these updates, I still see this as a bug fix because of the "at least" language.

[donmccurdy]

three.js will safely ignore morph attributes other than POSITION and NORMAL, so adding more (like TEXCOORD_n or COLOR_n) shouldn't be any problem. I agree that the spec has been clear that this was a possibility. It would certainly be interesting to have workflows for morphing other attributes.

EDIT: three.js will probably struggle if targets use a mix of attributes, e.g. the first target morphs POSITION and the second morphs TEXCOORD_n. But we can fix that if the need arises.