HDR lighting in linear RBG + ACES Film Tonemapping

[RobertBeckebans]

Light equations have been wrong in games for more than 14 years. See http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html

This is also a requirement for the Physically Based Rendering standard.

Current results: http://imgur.com/a/dKfLH

[RobertBeckebans]

TBH it is amazing how the 10 years old assets can look like with correct lighting. The old shaders just make the game cartoony.

[aFoxNamedMorris]

Wha... With the progress that is being made here... there's less and less an excuse for the Doom 3 (2004) modding community to avoid moving to BFG Edition. Fabulous.

[BielBdeLuna]

this is excellent looking! :+1: :+1: :+1: the original looks like the original Tron on steroids!

[romulus2k4]

I compiled this today, and it seems this is totally broken on AMD, can anyone else confirm this?

[RobertBeckebans]

Could you make a proper bug report with screenshots and a qconsole.log pastebin? Everything else is just wasting time.

[romulus2k4]

OKay, I have done as you have asked. Here are three screenshots I took from "Alpha Labs 1."

http://imgur.com/a/HqTeh

And here's the qconsole.log: https://paste.ee/p/jytT2

[ghost]

Your pc may be on acid. This issue may be linked to the other AMD based post. The only part of your log that I believe may be the cause is the following.

------------- Warnings ---------------
during DOOM 3: BFG Edition initialization...
WARNING: Unable to open resource file maps/_startup.resources
WARNING: file renderprogs/interaction.pixel, line 30: file 'renderprogs/BRDF.inc' not found
WARNING: file renderprogs/interaction.pixel, line 32: Could not strip dead code -- unknown token uniform

WARNING: file renderprogs/interactionSM.pixel, line 30: file 'renderprogs/BRDF.inc' not found
WARNING: file renderprogs/interactionSM.pixel, line 32: Could not strip dead code -- unknown token uniform

Seems a lot of the fragment shader fails are related to the BRDF shader.

[BielBdeLuna]

I've just compiled it this looks excellent!

[ghost]

@BielBdeLuna Any ideas about the BRDF issue for AMD users? The code fails to compile on VS 2013 on my system, so I can't check it out :(, Screenshots Robert linked looks great though.

[BielBdeLuna]

I'm not on Windows sorry, so IDK. No idea why Visual Studio is needed for, why you need a M$ program to make programs work on their OS? Users and sufferers of Windows, revolt against your oppressors! And about BRDF.inc missing, I have it in my renderprogs, have you copied the base folder from the source folder to the game folder, maybe Robert hasn't included his new GLSL code as hardcoded source yet, he's been doing so with other additions he has made, so you won't need the renderprogs folder once he has done it, but for the moment you might need to copy it.

[ghost]

@BielBdeLuna Lol another guy from another post also posted about the renderprogs files. I feel you about the whole M$ thing, I also use Linux on my other machines, but those GPU's are not good for anything 3D. I only use Windows on my main system for some games that really don't work with Wine. Thankfully that will change in the future as more devs make DX games more compatible. Just happy AMD refused M$'s offer to buy the company, they may be struggling financially, but always innovate computing, can't wait for Zen, now all we need is proper drivers.

[ghost]

@romulus2k4 As suggested by a user on another issue, try moving the renderprogs folder into your base folder.

Here is the link: https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/286#issuecomment-173301584

[romulus2k4]

I don't understand, I already have the "renderprogs" folder in my "base" folder?

[ghost]

@romulus2k4 If I understand correctly the source code already has built in renderprogs in the source code, then it creates the renderprogs folder and adds the render/shader code. So it may be because the renderprogs that are included separately with the new shaders needs to replace the others. So try copying over the renderprogs included in the RBdoom3-master and see if that works.

[ghost]

Just compiled after the ffmpeg fix, the game looks great, way brighter than the old D3. It kind of makes me think of the SOMA game. There are only three issues I've found, an average FPS of 15, died by jumping into a crate with no enemies around (was funny), and of course the old light in the other room making the door glow. I'll open the map at some late date in radiant and take a look at those doors. Maybe it's not occluding like it should.

[BielBdeLuna]

if you use git to get the source in your computer take a look on what has downloaded, if it has downloaded any file in the base folder in the source folder then you have to copy the base folder from the source over the base folder in the game folder

@yetta1 I bet this door problem has to do with portals, the light is on the "light side" of the portal and the door is in the same side of the portal, but the map brushes around the door, are in the player side of the portal, and maybe those brushes get culled in the light side of the portal, therefore they don't exist there and so they don't make a shadow when they should?

[ghost]

@BielBdeLuna That makes sense. I'll check the maps and do fixes, however I'm uncertain if we are allowed to redistribute the fixed maps as some sort of community patch.

[BielBdeLuna]

You can fix a map for yourself but you can't redistribute any id Software creation, you're free to create patches to extract and change the maps though, but I think this error could be accepted as a bug in the map making, and let it pass. Another thing would be to hunt the error in the portal system and kill it. The portal system is known to some times block off rooms inside of buildings from lights that are huge (like the sun) so that their center is several portals away. And so the light should enter but there is an invisible barrier that leaves the room in shadows, this invisible barrier is the portal.

this doesn't happen with ambient lights, like with fogs, because in the portal system there is an special requirement to not kill off those sort of lights if the portal is "fogged".

[nbohr1more]

Yeah, use something like WinMerge to create a patch and have end-users patch the x.map files.

It's possible that light leaking is due to precision issues in the latest MSVC versions (they don't support x87 FP instructions and thus reduce precision from 90-bit to whatever RBDOOM3 uses). At least we saw that in Vanilla (The Dark Mod) with MSVC 2013. (That and borked epsilon operations, and compiler optimizations that removed valid code...)

[BielBdeLuna]

I think it's not a MSVC issue as I in linux also see this issue.

[ghost]

I'll have to look into WinMerge, not sure how to do patches.