Open oldschooljarvis opened 9 years ago
Thanks for the detailed "wish list" :smile:
The cutout system will be decoupled by making the cutouts components. We're currently refactoring parts of the WebGLRenderer, changes like mentioned above will be implemented during this refactor.
I'm leaving this open in case anyone wants to add anything....
the user is free to define the cutout representing their DOM content.
But that's what I love about "mixed mode", is not having to worry about that. That's what makes Engine special. I don't want to think about that. I just want it to work. But if it's as easy as
let el = new DOMElement(node)
let cutout = new DOMElementCutout(node)
then I can live with that.
We are working on an implementation for a node to know the drawn size of the DOM and creating a cutout based on the border-radius so the user doesn't need to self define.
Eschew vertex-based cutouts
Does not a cutout also have a fragment shader? Farhad was telling me we could put shadows on the cutouts, implying fragment shaders.
@michaelobriena Awesome.
having the first item would make it such that those of us wishing to implement our own cutout system wouldn't have to rewrite most of WebGLRenderer to do so.
I could see that being really powerful in cases when a DOM element has a border radius or is clipped into arbitrary shapes using the CSS clip
property. I would agree that some control is needed in those scenarios, but at the top level there should be no control required for it to work with normal rectangular DOM elements (the default).
@alexanderGugel
A couple extra thoughts:
Thanks again, appreciate the feedback.
Having heard the GL side of things is slated for a major refactor, as well as having seen some of the writing on the wall, I figured now might be a good time to request certain features that might otherwise be untenable if not for an impending refactor.
So without further ado, here's my wish list:
1. Decouple the cutout system from WebGLRenderer
I would argue that the cutout system should not be an intrinsic part of WebGLRenderer. Per issue 313, barring a major leap like rasterization of DOM content (which is a long, long ways off), the only way complex cutouts can be reliably achieved is if the cutout system is exposed to the user, and the user is free to define the cutout representing their DOM content.
2. Eschew vertex-based cutouts in favor of a fragment-based system with blending support
Currently, the cutout system is based on vertex data (geometry). While this might be somewhat more efficient than alternatives, it's also not as capable. DOM images containing alpha opacity are the most glaring argument against the current system.
3. The cutout/blending system should support n layers
Specifically, n GL layers. Imagine the following scenario:
You have DOM content containing alpha opacity, some Famous GL content, as well as foreign (i.e. non-Famous) GL content. All of it needs to play nicely together.
Ideally, the system would first perform fragment depth testing across all layers, followed by a blending pass. The end result is you'd have DOM + n GL layers all coexisting peacefully, all respecting the same cutout state, with a single Canvas element.
4. Ability to specify a custom depth buffer precision for each layer
For my use case, I require a logarithmic depth buffer. Moreover, the aforementioned depth testing is worthless unless the depth value scale is homogenous across all tested layers.
5. Post-processing pipeline
I know this is already planned, so I'll just say I'm really looking forward to it. :-)
Conclusion
If nothing else, having the first item would make it such that those of us wishing to implement our own cutout system wouldn't have to rewrite most of WebGLRenderer to do so.
Thanks for reading! Looking forward to any input.