You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A long term goal is for the JS api is the ability to write a full raymarching shader from javascript with good performance.
A rewritten version of the glsl generating code is currently in progress in the "operators" branch, which is able to generate much more readable glsl code with variable names that match the original javascript. However this approach still has some challenges.
Unrolled loops:
In the new version, new variables defined in a loop will cause errors because when the loop is unrolled variables can be redefined causing name collisions. In both the new and old version, it is not possible to break out of a loop early because of unrolling. this makes a raymarching loop inefficient. the only way to break out of a for loop properly is to generate an actual glsl for loop. converting javascript for-loops to glsl will have its own challenges (what if its a loop iterating over a js array or map? can all cases of for loops be easily copied to glsl, like unconventional setting of loop bounds and conditions?). This may limit the use of some js features, but would make more readable, shorter glsl code, and could enable writing a basic raymarcher in js.
Functions:
If variables are declared inside a function (or inside a for loop), these variables will collide with variables of the same name in a different scope. One possible solution to this is to automatically wrap all function calls so that special scope prefixes are added to variables when executing inside a function or loop. It also could be possible to take the approach of generating actual glsl functions for JS ones (which would again make the glsl more readable), but in this case I think it would be too limiting for what someone might want to do with javascript functions. So probably better to continue inlining functions while adding a scope prefix.
<<<< don't worry, the world is almost over >>>>
The text was updated successfully, but these errors were encountered:
Yes, thanks so much for writing this up!! It'd be great to explore the scoped functions.
I wonder if there's a workaround that would give us the functionality we're looking for without breaking the existing js features. Eg. pure glsl loops, branching, and functions.
9-17-20 meeting notes
A long term goal is for the JS api is the ability to write a full raymarching shader from javascript with good performance.
A rewritten version of the glsl generating code is currently in progress in the "operators" branch, which is able to generate much more readable glsl code with variable names that match the original javascript. However this approach still has some challenges.
Unrolled loops:
In the new version, new variables defined in a loop will cause errors because when the loop is unrolled variables can be redefined causing name collisions. In both the new and old version, it is not possible to break out of a loop early because of unrolling. this makes a raymarching loop inefficient. the only way to break out of a for loop properly is to generate an actual glsl for loop. converting javascript for-loops to glsl will have its own challenges (what if its a loop iterating over a js array or map? can all cases of for loops be easily copied to glsl, like unconventional setting of loop bounds and conditions?). This may limit the use of some js features, but would make more readable, shorter glsl code, and could enable writing a basic raymarcher in js.
Functions:
If variables are declared inside a function (or inside a for loop), these variables will collide with variables of the same name in a different scope. One possible solution to this is to automatically wrap all function calls so that special scope prefixes are added to variables when executing inside a function or loop. It also could be possible to take the approach of generating actual glsl functions for JS ones (which would again make the glsl more readable), but in this case I think it would be too limiting for what someone might want to do with javascript functions. So probably better to continue inlining functions while adding a scope prefix.
<<<< don't worry, the world is almost over >>>>
The text was updated successfully, but these errors were encountered: