[p5.strands] Some comparisons are allowed by strands but disallowed by GLSL

[davepagurek]

Increasing access

I can write this in p5.strands:

getFinalColor((color) => {
color = [myMouse.x/200, 1, 0, 1]; // Yellow in RGBA (0-1 scale)
  if ( color < 2) {
    color = [1, 1, 1, 1]
  }
return color;
});

I don't get a p5.strands error; instead, it gives me a GLSL error:

An error with message "Whoops! Something went wrong initializing the shader:
Darn! An error occurred compiling the fragment shader: ERROR: 0:51: '<' : comparison operator only defined for scalars
ERROR: 0:51: '<' : wrong operand types - no operation '<' exists that takes a left-hand operand of type 'mediump 4-component vector of float' and a right operand of type 'const 4-component vector of float' (or there is no acceptable conversion)
" occurred inside the p5js library when validateParams/</< was called. If not stated otherwise, it might be an issue with the arguments passed to validateParams/</<. ([https://p5js.org/reference/p5/validateParams/</<)](https://p5js.org/reference/p5/validateParams/%3C/%3C))

This is pretty hard to parse. We should check for a valid comparison in boolean operators and throw a strands error earlier on if possible.

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build process
• Unit testing
• Internationalization
• Friendly errors
• Other (specify if possible)

Feature enhancement details

There are existing p5.strands error logger functions that we can be using for this.

[menacingly-coded]

I think the right approach is to add early validation checks in this function itself. Since this code already uses FES.userError(...) (see ir_builders.js around line 65:

p5.js/src/strands/ir_builders.js

Line 65 in 626996e

export function binaryOpNode(strandsContext, leftStrandsNode, rightArg, opCode) {

we can extend the logic here to validate invalid comparison operations before the shader is generated. This way, errors that would normally fail at GLSL compile time can be caught earlier and a clearer, Does this approach sound correct? @davepagurek

[davepagurek]

That sounds good @menacingly-coded !

[menacingly-coded]

I want to work on this issue. Please assign it to me. @davepagurek

[davepagurek]

Thanks!