 |
It is supposed to add one more stage of dmap process? Like what runParticle does for particle collisions (although I did not integrate it into dmap yet). |
 |
It will definitely need an in-engine command to generate reflection maps at all "probe" positions. I guess it would make sense to make that part of dmap eventually? |
|
|
Yes, dmap looks like the best place, otherwise mappers will have to do some manual steps. You can do it like it works with runAAS and runParticle: create a new compiler tool, and after some time integrate it into dmap (like AAS). |
 |
RBDOOM-3-BFG has made some new progress on the Probes branch: https://github.com/id-Software/DOOM-3-BFG/compare/master...RobertBeckebans:497-light-probe-interpolation Autospawn env probes in the center of BSP areas: https://github.com/RobertBeckebans/RBDOOM-3-BFG/commit/2498a171494404e01f049c334e61e5ecdfb8f0c3 |
|
|
Moving off the 2.11 roadmap |
 |
This is a feature I'd absolutely love having on my maps if possible. At the moment the only way to get any environment lighting is using a cubic sky light for one of the skyboxes, which typically means having to use that skybox for your portal_sky as well so it makes sense visually. The biggest issue with those is lack of accuracy: You only get light matching the skybox outside, inside it doesn't make sense to see the sky's reflection at all but since the light must cover the entire map it's unavoidable. An ideal but likely impossible solution would be a single screen-space reflection updated in realtime, in our case likely a cubemap feed redrawn from the player's view every X frames. This would be the most accurate but also very performance expensive; We could render the reflection cubemap on a separate FBO with low resolution like 256 x 256 since those don't need high accuracy, but even then it involves opening up all portal areas around the player since it's a 360* view which is a costly step in and of itself. Maybe a separate feature and menu option for those who feel they can handle it? Biggest advantage is this would work with any existing FM since it would be universal and the mapper doesn't need to place light sources for it. If that can't be a solution the next best thing are indeed light probes which compile a cubemap in memory once at map start. They could have a spawnarg to update every X frames for mappers that are brave enough, image resolution could depend on the light size similarly to how I understand shadow maps work. This way you at least have one environment matching each room or part of a town instead of something universal to the whole map. You'd need to place different lights in different areas and blend them together the right way, with proper fading and fading in between I can see it working out. Unlike the existing cube skies, I hope such an implementation will also allow for specular reflections. At the moment the skybox lights only provide diffuse lighting: One of the features I always wanted was having all surfaces with a specular channel in radius of such lights reflect the cubemap, so you can see it move and bend with the normal maps of surfaces as you walk or look around. Some window models and the polished versions of a few stone textures do this with with a fixed generic cubemap, the goal would be having it work automatically on all textures that have a specular component. |
- Anonymous
