There was a question on SO:
The author came up with using
NaN values in an attribute for positions.
Is it a good practice to use
NaN in attributes?
Specifically for that case with lines in one geometry I used a custom attribute for visibility +
discard on visibility condition in the fragment shader.
No, you should avoid
NaN values. The problem is that typed arrays handled
NaN values differently. If you pass a
NaN value to a
Uint8Array(), it is interpreted as
0. If you do the same test with
NaN value is preserved and passed to the shader.
NaN values in attributes like
position will break certain
three.js features like view frustum culling since the engine expects valid numerical data.
Since the beginning, that idea with NaN seemed doubtful for me
Thanks for explanation
The frustrum culling and similar features should disregard NaN values instead of failing on them. NaN values are valid OpenGL according to spec, used for this very purpose.
NaN values are valid OpenGL according to spec
Well, of course,
NaN is a floating point value. It can’t be represented by a
Uint8. That behavior could be surprising for some users, though. On the other hand, using non-float typed arrays in THREE is a bit advanced, so anyone that would run into this behavior would also be likely to understand what
My two cents is that this approach is perfectly fine and that I agree with @jadware that THREE should be more forgiving of
NaN (if possible without adding a lot of complexity). The workaround in the answer is also interesting.
Here is another approach.
NaNs, no shaders. Just
THREE.LineSegments() with a single indexed
For the reference: