Closed
Bug 1037563
Opened 11 years ago
Closed 2 years ago
CSS Shooter demo has buggy rendering
Categories
(Core :: Graphics: Layers, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: BenWa, Unassigned)
References
()
Details
STR: www.keithclark.co.uk/labs/3dcss/demo/
I know our code only tries to sort 100 layers max so we might just be hitting this. Matt?
Flags: needinfo?(matt.woodrow)
| Reporter | ||
Comment 1•11 years ago
|
||
Comment 2•11 years ago
|
||
Yeah, we also don't deal well with planes that should touch at the edges but end up intersect because of floating point precision.
We just need to implement plane splitting for this to work well.
Flags: needinfo?(matt.woodrow)
Comment 3•11 years ago
|
||
Kip mentioned that he would be interested in doing this, not sure if he has time for it at the moment though.
Comment 4•11 years ago
|
||
I am still interested in doing this, but it will be secondary to my current objectives. (I can moonlight it).
Depending on how many layers are transformed, I can imagine at least a couple of solutions:
#1: If < 100 layers with lots of transparency, little overdraw, or expensive to determine which layers are fully opaque:
Insert the transformed polygons representing the layers into a BSP tree. Traverse the BSP tree to extract them in a perfect sorted order with clipping applied inherently. This may perform unnecessary clipping; however, the amount of generated geometry will still be very manageable even for a low-end mobile SoC GPU. As no Z-Buffer is involved, there will be some overfill which will hurt performance, especially on mobile. Additionally, vertex processing will occur entirely on the CPU which is much slower for the task. It is possible to anti-alias the edges of the layers without supersampling (utilize a distance-to-edge shader)
#2: If < 100 layers and expect many fully opaque layers:
Insert the transformed polygons representing the layers into a quadtree. Use the quadtree to identify and clip against previously inserted, intersecting polygons. Clip polygons against portions of fully opaque polygons which are nearer in z-order; discard the clipped polygon pieces that are fully occluded. Need only to sort the polygons with transparency, which will be drawn after all of now non-overlapping opaque layers. We avoid unnecessary overfill; however, this algorithm will use an exponentially increasing number of CPU cycles as the number of intersecting layers increases. It is possible to anti-alias the edges of the layers without super-sampling (utilize a distance-to-edge shader) Additionally, vertex processing will occur entirely on the CPU which is much slower for the task.
#3: If > 100 layers and most of them are fully opaque: Enable the Z-Buffer. By enabling the Z-Buffer we can transform all of the fully opaque geometry on the GPU, which is several orders of magnitude faster for the task. We will also take advantage of occlusion culling, tile based rendering, deferred texture fetch, and other optimizations implemented in the GPU hardware. This will drastically reduce the memory bandwidth consumption at the cost of using a bit more vram for the Z-Buffer. Any transparent layers will need to be rendered following the opaque layers with the Z-Buffer disabled and algorithm #1 or #2 applied. In order to anti-alias the layer edges, either super-sampling or a selectively blurring post-fx pass such as FXAA or SMAA will need to be applied.
#4: Compute shader. A compute shader can be utilized to accelerate the clipping functions above by rendering an intermediate low-resolution buffer containing occlusion information. A screen-space tile-by-tile render can make optimizations based on the contents of this buffer to avoid unnecessary texture loading and polygon clipping. This technique relies on features that will not be available on all platforms, so a CPU based implementation must be maintained in parallel for fall-back purposes.
If the most common use case scenarios currently are to have just a few transformed layers on a page, I would suggest implementing a solution similar to #1, as it solves the problem with "perfect" clipping; allows for cheap, high quality anti-aliasing; and can be a self-contained implementation with less risk.
The CSS transform based shooter demo referenced by this bug will not be able to reach the potential level of performance as a WebGL implementation without enabling the Z-Buffer as in option #3. Additionally, for it to have the same quality, we would have to generate a mip-map chain for the layers at run-time to enable trilinear or anisotropic texture filtering.
For the anti-aliasing aspect, see Bug 766345
Updated•3 years ago
|
Severity: normal → S3
Comment 5•2 years ago
|
||
Unable to reproduce
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•