Improving scissor usage

[lexaknyazev]

Currently, states.functions.scissor is defined as

Floating-point value passed to scissor(). [x, y, width, height]. The default is the dimensions of the canvas when the WebGL context is created. width and height must be greater than zero.

At the same time, there is no way in glTF to define window and/or viewport dimensions, so scissor state is almost useless (since it uses window coordinates) especially in the WebGL context, because HTML canvas can have any random dimensions (and they change with window resizing and full-screen toggling).

VIEWPORT uniform parameter can't help with this, because it has the opposite purpose: provide viewport info to shader.

I can see two possible solutions for this issue:

1. Add viewport property to states.functions dictionary and make it required when scissor is present.
   Add also width and height to asset and/or scene to declare desired window size (of course, runtime can scale everything to actual canvas dimensions). Such approach will align glTF with other multimedia formats (think of image or video) and will also make embedding glTF assets into web pages more predictable.
2. Remove scissor from states.functions (and SCISSOR_TEST from states.enable).

For more flexible viewport / scissor positioning (relative, absolute, fixed, etc) something like "window layout" extension could be proposed later.

[pjcozzi]

I suggest we push this post 1.0.1.

I am not sure about adding viewport and friends until we have concrete use cases that people are asking for (then it would be OK, of course) nor am I sure about removing scissor and then adding it back later.

[lexaknyazev]

glTF declares itself as a "JPEG for 3D", so interoperability of the base spec must be one the top format's priorities. Current state of handling scissor is neither flexible for real usage nor interoperable (think of possible runtime resizes).

If we don't have enough time to collect people's feedback, I'd prefer to remove it (afair, stencil support was removed from 1.0 for similar reasons).
Otherwise, we can define a bare minimum (optional viewport defaulting to canvas size and explicit asset's dimensions) to make scissor support useful.

[pjcozzi]

I am having a hard time coming up with a real use case for the current form other than if an app knows it will have a fixed viewport, e.g., as an embed, not a fullscreen app.

I suppose since no one is using this AFAIK if it would be fine to remove and add back when full support is thought through.

Can you open a PR to update the spec and check the sample models?

[lexaknyazev]

Sample models are clean.

[lexaknyazev]

See #681.

[pjcozzi]

Updated in #826