google / google/filament

Have IBL as a light type rather than being bound per scene

Open
#6,101 3 comments 1 reaction 1 assignee Claimed by @pixelflinger View on GitHub
Dominant language
C++
Stars
20.5k
Forks
2.3k
Avg merge
2d 14h
Merged PRs (30d)
83

Description

**Is your feature request related to a problem? Please describe.**
Right now you are limited to a single IBL on your entire scene, this can work fine for simple programs like model viewers and tech demos but quickly break as you scale the complexity of your scene

**Describe the solution you'd like**
It would be nice if there would be a new light type to assign an IBL per region rather the entire scene, this would also help to unify direct and indirect illumination types, akin to this:

https://user-images.githubusercontent.com/6563447/192097890-33e4fbb9-ed86-4c72-91dd-cefe1ab1c6de.mp4

If that fragment pixel is not lit by any indirect light, then it falls back to the IBL provided by the scene

To avoid sampler pressure, the IBL cubemap textures can be copied on the backend to a `SamplerType::SAMPLER_CUBEMAP_ARRAY` so it all uses a single sampler on runtime

This would not increase scene rendering complexity as these lights can be culled using clustered shading, as a bonus these can also have parallax as you have radius information of the indirect light

The API for creating such light could look something like this:
```C++
LightManager::Builder(LightManager::Type::INDIRECT)
.radius( filament::Aabb& radius)
.transform( filament::math::mat4f& transform )
.reflections( filament::Texture* cubemap )
.falloff( float easingRadius ) // For blending edge easing with multiple IBL lights
.build(*m_pEngine, filamentLight);
```

**OS and backend**
Should be available on all OS and backends, I believe even GLES supports cubemap arrays

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.