|
| IrradianceFieldRaster (IrradianceField *creator) |
|
virtual | ~IrradianceFieldRaster () |
|
void | createWorkspace () |
|
void | destroyWorkspace () |
|
void | operator delete (void *ptr) |
|
void | operator delete (void *ptr, const char *, int, const char *) |
|
void | operator delete (void *ptr, void *) |
|
void | operator delete[] (void *ptr) |
|
void | operator delete[] (void *ptr, const char *, int, const char *) |
|
void * | operator new (size_t sz) |
|
void * | operator new (size_t sz, const char *file, int line, const char *func) |
| operator new, with debug line info More...
|
|
void * | operator new (size_t sz, void *ptr) |
| placement operator new More...
|
|
void * | operator new[] (size_t sz) |
|
void * | operator new[] (size_t sz, const char *file, int line, const char *func) |
| array operator new, with debug line info More...
|
|
void | renderProbes (uint32 probesPerFrame) |
|
Implements IrradianceField, but generating results via cubemap rasterization.
GPUs are normally slow for rasterization at row resolution thus not well suited (hence raytracing or voxelization are better suited) but currently voxelization either requires a lot of memory or a slow pre-build process, hence a raster-based approach is less invasive and in many cases more practical.
A: Because:
1. We require to convert the depth buffer of each side into a cubemap.
We could reuse the depth compression though. It's not accurate information
but it may be good enough
2. Resolution needs to be low (e.g. 16x16 or so). Workaroundeable if
we sample higher mips.
3. PCC provides no guarantees the cubemaps are aligned in a perfect 3D grid.
PccPerPixelGridPlacement generates the cubemaps in a grid alignment, but
the camera are not guaranteed to be at the center of each probe
In short, it may be possible, but there are several issues to workaround, hence it is just easier to render the information we need