HN user
Like I said, Sceneform used Filament (not the other way around). I know of a few Google products that use Filament but having left the company I'm not sure what I'm at liberty to talk about unfortunately. Btw, I'm one of the authors of Filament :)
Sceneform != Filament. Sceneform was an AR-oriented framework that used Filament as its renderer. Filament itself is very much alive and under active development.
You are absolutely right, this diagram is misleading and I've been meaning to replace it with one of my own since forever but it has fallen deep at the bottom of long list of things to do (including many, many things I would like to describe in that document, like our approach to transmission/absorption/refraction, our post-processing pipeline, etc.).
It's used on desktop and iOS as well.
Filament is used at Google.
That subsurface scattering model is not what you would use for skin, etc. It's a fairly simple approximation similar to what Unreal and Frostbite have used (use?) in the past to cheaply approximate somewhat translucent materials. It's mostly still a TODO because it's not that interesting.
Jetpack Compose was announced before SwiftUI :)
The engine itself only has two external dependencies: STL (internal use only, not part of the APIs) and robin-map. The (optional) Vulkan backend adds a third one: vkmemalloc.
The host tools (material compiler, etc.) do have more dependencies indeed.
The engine was never intended to support WebGL. We only used WebGL to quickly prototype the lighting system.
We just serve straight from the source tree so it's not out of date :)
It's similar techniques, just better because they can afford more effects on a PS4 :)
Looks like the page wasn't able to load all of its resources. Try to refresh the page until it works. I should make an offline version that doesn't require online processing.
There are several spectral renderers out there, such as Weta Digital's Manuka. I don't know if they bother with parts of the EM spectrum that are outside of the visible range though. I imagine UVs can be important to model in some situations.
Thank you! This is exactly the same render that I get. I could try and widen the column. I've grown to like the narrower width when reading graphics papers like this but I understand it's not for everybody.
The WebGL demo was the initial prototype of Filament :)
Would you mind sharing a screenshot somewhere? I'm just using Markdeep's default CSS and the font size seems reasonable on all my screen. I'd be happy to try and tweak it though.
Glad you like it. We found it hard to piece together all the information we needed and after reading hundreds of papers and presentations we figured that writing such a document would be helpful to beginners like us (in this field that is).
You must be mistaking me with someone else.
We are trying to have all the tools available in ADT/monitor. Systrace can actually be invoked directly from ADT/monitor, there's a button in the toolbar for this.
Frame buffers are 32 bits, not 24 bits. You must also take into account the cost of blending. Also, you don't necessarily get all the bandwidth (especially when the device is not running at full clock.)
Android does not use the depth buffer. The UI toolkit draws back to front. We are thinking about ways to improve this but most apps draw blended primitives back to front. An optimization I want to get in is to resort the render tree to batch commands by type and state. A side effect of this will be the ability to cull invisible primitives.
The stencil is not used at the moment (well... that's actually how overdraw debugging is implemented) because the hardware renderer only support rectangular clipping regions and thus relies on the scissor instead. Given how the original 2D API was designed, using the stencil buffer for clipping could eat up quite a bit of bandwidth or require a rather complex implementation.
It is planned to start using the stencil buffer to support non-rectangular clipping regions but this will have a cost.
Remember that the GPU rendering pipeline was written for an API that was never designed to run on the GPU and some obvious optimizations applied to traditional rendering engines do not necessarily apply.
You are right but apps are not in control of the shaders, at least not directly. It is possible to make the View system use complicated shaders but it's rare and I've never seen this be the cause of performance issues (except when we had bugs in our shaders generation code.)
Most UI elements are drawn with a quad and trivial shaders (a couple of multiplications in the vertex shader, a texture lookup and modulate in the fragment shader.)
In my years of working on Android I have learned that poor framerate is most of the time (not always) a combination of blocking the UI thread for too long and drawing too much.
I should have made this clearer but a lot of overdraw above 2x will likely be one of the causes of performance issue. Not all devices will behave the same of course but it's a reasonable average (devices with more bandwidth tend to have higher screen resolutions.)
What's important to remember however is that overdraw often indicates other problems. This typically the application uses more views than it needs. This impacts performance in other ways: higher memory consumption, larger tree that takes longer to manager and traverse, longer startup times, more work for the renderer (sorting display lists, managing OpenGL state, etc.)