 |
Committed a lot of changes in svn rev 10106: 1) Now we support image programs for cubemaps (separate set of commands). See R_LoadImageProgramCubeMap, R_ParsePastImageProgramCubeMap, R_ParseImageProgramCubeMap_r in renderer/Image_program.cpp. 2) It is now possible to set layout of single cubemap image, instead of setting it for the whole cubemap-image program. Looks like this: cubeMap bakeAmbientDiffuse(cameraLayout(env/lights/cubesky)) 3) Restored shader code which fetches diffuse/specular term from two separate cubemaps in case of ambient light. 4) Restored passing cubemaps on C++ side via separate uniforms (new backend only, not finished). 5) Added _whiteCubeMap global image. 6) makeIrradiance cubemap function renamed to bakeAmbientDiffuse/bakeAmbientSpecular, code moved to renderer/Image_program.cpp. 7) Completely reimplemented bakeAmbientXXX using integration over spherical coordinates, simplified CPU cubemap sampler. My TODO list here: 1) Add CPU-side sampler to imageBlock_t and move cubemap sampling there. 2) Decide what's the right place to store ambient-diffuse and ambient-specular cubemaps (note: lightFalloffCubeMap is awful) 3) Fix C++-side support in old backend. 4) Look at makeAmbientMap console command: fix, rename, reuse more code with image-program case. |
|
|
Point 2 done in svn rev 10120. Now one can set two new parameters on ambient light: lightAmbientDiffuse {cubemap program here} lightAmbientSpecular {cubemap program here} If at least one of them is set, then normal-based modulator is computed from them. If none of them is set, then the old hacky "light from above" modulator is used instead. Note that ambientCubicLight keyword no longer exists, since it serves no purpose. But you can set ambientLight and cubicLight together if you want. The "cubicLight" flag controls only how projection texture is used (cubemap vs 2D). Currently it also controls falloff, which will hopefully be changed in 0005835. Here is full example of an ambient light using this feature: lights/ambientCube/cubeSky { ambientLight lightAmbientDiffuse bakeAmbientDiffuse(cameraLayout(env/lights/cubesky)) lightAmbientSpecular bakeAmbientSpecular(cameraLayout(env/lights/cubesky)) { map lights/squarelight_amb.tga colored zeroClamp } } |
|
|
A bunch of more commits here! Some bugfixes: r10122 Don't bake ambient in parallel (deadlocks on nested parallelism), warn about color clamping. r10123 Fixed fetch direction for ambient specular. A new command which should ideally display a cubemap around you... although I suspect it does not work well yet. r10124 Supported "testimage cubemap XXX" command. The p.1 of TODO above --- CPU-side textures sampling, both 2D textures and cubemaps (although NOT seamless). r10125 Implemented full code for sampling textures on CPU, including filtering and cubemaps. Some attempts and improving precision and smoothness, although I'm afraid it's still not good: r10126 Added Bayer dithering in integrated function, accumulate output in floats. r10129 Removed 2/5 scale multiplier from ambient bake functions and shader. r10131 Downscale input env map to output size, also randomize X/Y axes rotation for every output pixel. Some refactoring and fixed old backend (p.3): r10130 Supported normal-indexed ambient in old backend, removed special ambient code, pass diffuse/specular flags separately. And finally, p.4 for the command is fixed, although I see some confusion in envmap conventions: r10132 Supposedly fixed makeAmbientMap command. |
 |
I'm trying to make a new little FM, one of the things I always do in mine is using an ambient cube light matching the skybox: Currently it's the only way to get realistic environment lighting, offering both diffuse and specular with respect to the normal map on every surface. I did it before as a test but this time noticed the light texture is no longer working and was sent to this ticket as an answer. First I noticed the default definitions are broken, wanted to note this in case they got forgotten. In tdm_textures_base01.pk4 all lights/ambientCube/* defs in materials/tdm_cubeLights.mtr still use the ambientCubicLight flag which you mentioned was replaced. I'm on the latest development version (dev16650-10157) maybe this can be fixed for the next update. Thus in the meantime I tried making my own copy in a custom material, but for some reason those also refuse to work. Since the skybox has a nice and detailed contrast I tried your above example with the texture "lights/ambientCube/skybox_mountain_sunset_cube": I get some sort of custom lighting, but even with white color for maximum intensity I see no shine or bumpmap detail on surfaces. Is this a bug or am I doing something wrong? I wish having to manually set a cube light matching the exact skybox wasn't necessary to begin with, if there was a better way to automate realistic lighting / reflections. Since PBR reflections using SSR are likely not planned anytime soon, a (hopefully) easy solution would be the ability to use the active sky cubemap projected from info_portalsky as a light texture: You'd get the shine from outdoor within indoor areas, but other than that it would be accurate to the active map and much better than having to pick a generic prebuilt image. Essentially textures/smf/portal_sky for ambient lights. Would that be difficult to support with those changes? |
 |
Try something like this: lights/ambientCube/cubeSky_mountain_sunset { ambientLight lightAmbientDiffuse bakeAmbientDiffuse(cameraLayout(env/skyboxes/skybox_mountain_sunset/mountain_sunset)) lightAmbientSpecular bakeAmbientSpecular(cameraLayout(env/skyboxes/skybox_mountain_sunset/mountain_sunset)) lightFalloffImage makeintensity( textures/lights/ambientlightnfo) { forceHighQuality map textures/lights/ambientlightnfo_amb colored zeroClamp } } The "lights/squarelight_amb.tga" has a very short falloff. That said, you shouldn't be using skybox images anyway. The advised practice is to use an external application to make irradiance maps. See: https://forums.thedarkmod.com/index.php?/topic/19803-tutorial-image-based-lighting-workflows-for-tdm/ |
|
|
Just tried and it doesn't seem to work either, tested it both with and without the "_b" in the image path. I appear to get the diffuse ambience but no specular, nothing moves with the camera as I walk like it did before when I tried this. Attached screenshots of my light in DR and the material with the result I get in-world: With "_color 1 1 1" it should be extremely bright and shining on top of everything. What am I missing? Using an external program or command to (re)generate cubemaps per area whenever you make changes is likely too bothersome for most mappers practically. What would help tremendously is one-time envmap baking in the engine: Lights with the flag should compile a cubemap in memory during the first frame after the map was loaded... if a mapper considers the performance loss acceptable we could even allow setting it to realtime so the light bakes its cubemap every X frames. I think this would be perfect and doing it the right way: Every room can its own irradiance which accurately reflects the interior of that room, without the mapper having to do a crazy amount of extra work manually. Would require the engine knowing to produce a cubemap on its own... you can save screenshots with F12 and this would be the same thing just in cubemap format and stored as a temporary texture set. What are your thoughts on this solution? |
|
|
Try removing the bakeAmbientSpecular program from the specular stage: lightAmbientSpecular cameraLayout(env/skyboxes/skybox_mountain_sunset/mountain_sunset) |
|
|
I think Cabalistic intended to implement light probes (0005239), which would basically replace this functionality with something much saner. Until then, maybe just suspend this whole feature? |
|
|
Commenting out the lightAmbientSpecular line doesn't have any noticeable changes... if I disable lightAmbientDiffuse instead everything becomes super bright, even then there's no specular reflection. I'll probably leave it at what I achieved since I seem to get the cubemap diffuse at least, I think only specular isn't working to also get the reflections. I'm presuming the new shaders are missing something as the same effect as before is no longer possible. For reference I found an old screenshot from a FM I was working on two years ago: At full intensity it made the noblewoman so shiny she appeared made of glass, no texture or material changes for her just the extra light... the effect looked best on bricks and other surfaces which had a more realistic result. |
|
|
The "extra shine effect" is incorrect. The intended appearance should be: https://media.moddb.com/images/members/1/442/441719/post-3763-0-01556000-1472191005.jpg It should look like conventional probe lighting or Half Life 2 cubemap lighting. This was working in 2.05 ( ARB shaders ) but was broken when we moved to GLSL In 2.06 and newer, the workaround was to tame that effect via the use of 3rd party Irradiance map software or use the nospecular keyword on the ambient light. |
|
|
That does look most realistic so maybe it's the correct result after all. It seems to add some subtle shine too, perhaps I need different materials to see it properly. I remember the reflection was unnaturally strong by default, I had to tone down the light intensity to make it look right. |
|
|
Wanted to clarify as to not leave the impression something might be broken when it's not: Upon closer inspection, I can confirm the new cube light shaders are in fact behaving as intended. It's just extremely subtle even at full light intensity, which can cause the impression the lights aren't working at all. I accidentally noticed after looking at a brick wall in an unlit area: You can see the hues of blue and orange coming from the skybox image, which do in fact respect direction and the normal map bump. Screenshot attached, can be seen if you take a close look. The default definitions in tdm_cubeLights.mtr are still outdated in TDM 2.11 Beta 1: Just a reminder if they can be fixed before the release so FM authors don't need to override them as I'm presently doing... or removed if for some reason anyone's against the defaults still being there, I find them helpful and convenient to have. cubelight.jpg (217,367 bytes) |
|
|
The definitions were updated in svn rev 16660. |
|
|
This has at least feature parity with 2.06 to 2.10 so I consider this issue complete for 2.11 Future development will happen either in 0005239 or another (new) tracker |
- Anonymous
