for loops with floats of unspecified increments?

    Nov 21 2015 | 2:56 am
    I am porting a few shaders that contain for loops to GenExpr . Integers are no problem because 1 is the natural increment.
    for(int i = 0.; i < 100.; i++) easily translates to for(i=0.; i
    How are float increments handled when porting code that doesn't specify an increment? The compiler doesn't like ++ example: for(float j = -1.; j < 1.01; j++)
    There are no references to float precision anywhere else in the code. Is there a default value?

    • Nov 21 2015 | 11:28 am
      don't know much about shader programming - is in the shader world j++ not short for j = j + 1 ? How could you increment without knowing how much? - IMHO i'd say you'll need to specify it at some point, i.e:
      for( j = - 1.; j < 1.01; j = j + 0.1) { }
      or substitute 0.1 or whatever increment value you need with a param in case is needs to be changeable.
      ... but maybe i am missing a point here...
    • Nov 21 2015 | 5:18 pm
      Simply, GenExpr does not support i++ or i--, but i+=1 and i-=1 (or i=i+1 and i=i-1) are equivalent. And of course you can put a float there instead of the 1.
    • Nov 23 2015 | 7:32 am
      Yes.. I'm aware of what you both mentioned.. which is why I don't understand the first for loop in this code: Picking an arbitrary number doesn't seem like the way to go.
    • Nov 23 2015 | 4:17 pm
      I'm confused -- what is arbitrary here? All the loops in the shadertoy example use i++ or j++, which means i=i+1 and j=j+1.
      This looks very close to the shadertoy:
    • Nov 24 2015 | 5:02 am
      Oh wow.. I should have picked a smaller example or posted code I already had. Turns out my problem was improper use of p as a variable when defining functions. It was hard to spot because the patch was compiling. Thank you!
      My confusion re: for loops was based on the assumption that it's not possible to get to 1.01 by whole numbers. After seeing your example, it hit me... It's not about reaching 1.01 it's about reaching 1. Shadertoy distinguishes ints and floats. Either for the sake of expense or brevity, some choose not to cast floats to ints when looping. My guess is that floating point imprecision makes 1.01 a safer choice to ensure the loop reaches 1. Yeah?
      Anyway.. here is my version after you helped bring it to life. I think you dropped the last component of a vector in line 97 of your patch (it should include rd.z) and something is weird in the math with the original code, causing grayscale output. I messed with it to get some color and broke out some params. Thanks again for the help!