Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review operators branch, evaluate viability of new approach #47

Open
PWhiddy opened this issue Sep 18, 2020 · 2 comments
Open

Review operators branch, evaluate viability of new approach #47

PWhiddy opened this issue Sep 18, 2020 · 2 comments
Assignees

Comments

@PWhiddy
Copy link
Member

PWhiddy commented Sep 18, 2020

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 >>>>

@torinmb
Copy link
Member

torinmb commented Sep 18, 2020

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.

@PWhiddy
Copy link
Member Author

PWhiddy commented Sep 21, 2020

There will have to be compromises no matter what I think. To understand which are the right ones to make we need to consider many examples

let shapes = [() => sphere(0.5), () => sphere(0.1), () => box(0.2,0.2,0.2)];
let sz = shapes.length;
for (let i=0; i<sz; i++) {
    color(i/3, i/3, i/3);
    shapes[i]();
}

What glsl should be generated for this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants