The Big List of Facet TODOs
Without relying on the AST, that is.
float(float(x)) => float(x),
float(x) => x, if x is known to be float
These will be useful when we have user-defined GLSL.
Streams of value-generating expressions seem appropriate, since we can constrain the generator to be finite.
functions like cosh which just build other expressions should have stricter type checking.
It should be possible to implement some form of static checking for Shade.make when passing functions.
Right now the algorithm in place is correct, but conservative. Ideally, I will want to propagate BDDs up the expression tree and check them
Batches can be drawn in different modes, currently:
- “regular” drawing
- additive blending
- alpha-blended
But scenes can also be rendered in different modes, currently
- regular drawing mode
- picking mode
- depth unproject mode
These two possibilities interact, and the result is a double dispatch, currently implemented badly on Facet.DrawingMode.*
This should be fixed.
Namely, the Facet.DrawingMode.<foo>.set_<bar>_caps functions dispatch on both foo and bar.
One better solution is to have a dictionary and dispatch on (<foo>, <bar>) pairs.
This would pave the way for extensible batch drawing modes. But extending rendering modes is not as easy because, for example, the picking procedure requires extra state to be kept around. This should be designed carefully (in other words, I’m afraid of trying it out right now)
Part of it exists throughout Facet, but it’s scattered and untested.
This class would expose Shade functions to perform transformations. A cool demo would be a real non-linear fisheye distortion projection. Obviously tesselation would be necessary, but it’d get the point across.
The advantage here is that I could get different attributes from a single bound array buffer. This would reduce the overhead of binding the different attributes when switching state.
The main difficulty is that I currently assume a one-to-one relationship between array buffers and attributes throughout the API.
The way to do this is to add underscore_equivalents of the GLSL ugly camelCase functions. This way, people familiar with GLSL can use them, while people coming directly to Facet will use underscore
One possibility is to create a WebGLObject prototype that knows how to turn itself into a Shade expression
It is very convenient to use runtime type checking to get polymorphism, but it seems like it tends to proliferate along the code. I should try to consolidate all these calls in a single API of some sort.
I’ve been seeing a lot of infinite loops because of co-recursion in constant_value. What do I do about it?
Update: the issue here is that many expressions lack a true definition of element(), and so when element(i) returns element.at(i), at(i).element() runs the risk of diverging.
This should go together with writing the semantics for Shade expressions.
functions like cosh which just build other expressions should have stricter type checking.
This means multiple contexts, and lots of things are going to break. We already have set_context, but many calls use a possibly stale context on the closure scope. A code review and tests are in order.
Now that I figured out a nice way to make aligned rects work, I should extend this to lines, etc. The main problem is interaction with attribute_buffer, but that’s inevitable without geometry shaders. I’ll need documentation.
According to the spec, they must be square. But I can create them in WebGL without any trouble. I wonder if things will break.
I’ve done this one-off in the beauty of roots demo. Maybe I shouldn’t integrate it and leave it instead to app writers. But it’s a type of interaction that’s bound to be necessary over and over again…