id Tech Forums

General Category => Strutt your stuff! => Topic started by: eXistence on April 10, 2016, 12:35:13 PM

Title: fhDOOM (modernized idTech4)
Post by: eXistence on April 10, 2016, 12:35:13 PM
Hi folks,
since some time i am playing around with the original Doom 3 engine. At first i was just exploring the code and getting a feel for how certain things work. I applied more and more small changes, just for making it easier for me to work with the code (like making it compile with a modern VisualStudio). As a part of this endeavour, i ported the renderer from fixed-function/ARB2 to modern GLSL-based OpenGL. After that was done, experimenting with some more modern rendering features (like soft shadows) seemed feasible and worthwhile.

Here are some of the core changes:

(https://github.com/existence/fhDOOM/raw/master/doc/screenshots/shadowmapping2_on_tn.jpg)(https://github.com/existence/fhDOOM/raw/master/doc/screenshots/shadowmapping4_on_tn.jpg)(https://github.com/existence/fhDOOM/raw/master/doc/screenshots/lighteditor_tn.jpg)

Of course its open source and available on github: https://github.com/eXistence/fhDOOM
You can also download a binary release here:
http://www.facinghell.com/fhdoom/fhDOOM-1.5.0-1405.zip
http://www.facinghell.com/fhdoom/fhDOOM-1.5.1-1413.zip (Update: 2016-06-27 details (http://idtechforums.fuzzylogicinc.com/index.php?topic=404.msg5118#msg5118))
http://www.facinghell.com/fhdoom/fhDOOM-1.5.2-1414.zip (Update: 2017-08-16 details (http://idtechforums.fuzzylogicinc.com/index.php?topic=404.msg6210#msg6210))

If you want to check out the code or compile it yourself, feel free to do so, but be warned: a lot of things are still in a state of flux and quite messy :)

My version of the engine works fine on my machines and first benchmarks look good, but both of my machines (Windows workstation, Linux notebook) are quite dated. There are still tons of things to fix and improve (see github page) and i already encountered some serious issues with AMD hardware and implemented a quick workaround for it (at the expense of performance, nVidia is fine though). I am working on the AMD issue to get an actual solution, but i would like to get some more feedback, especially from modern nVidia and Intel systems. I did some simple benchmark runs with 'timeDemo demo1.demo', but i am not sure if those results are reliable because they look just a bit too good.

I would be happy, if some of you could help me here: give it a try, give me some feedback, run some benchmarks :)

Thx in advance!
Title: Re: fhDOOM (modernized idTech4)
Post by: oneofthe8devilz on April 10, 2016, 01:29:09 PM
Amazing !

It was about time for someone to update the original Doom3 1.3.1 renderer and release it.

I just ran the intro scene and the new shadowmapping looks really nice !

Looks like it is quite taxing on the system but I need to run more in-depth testing to give detailed feedback.

Is custom gamecode (gamex86.dll) supported out of the box with your build ? (are we able to run existing mods with your build without the need to recompile ?)

Thanks for your contribution and welcome to the community :)
Title: Re: fhDOOM (modernized idTech4)
Post by: eXistence on April 10, 2016, 03:08:18 PM
I just added some info about new/changed cvars to the github page (if you want to play with this kind of stuff).

@oneofthe8devilz: thanks for looking at it :) regarding customcode: mod support is pretty much unchanged. I have not explicitly tested it, but you should be able to load a custom fhGame-x86.dll. That beeing said, i am not sure you can load a gamex86.dll from the original game (by renaming it). I don't think so.... never tried that. I may take a look at it later.
Title: Re: fhDOOM (modernized idTech4)
Post by: trebor on April 10, 2016, 03:28:51 PM
A Qt based light editor! Nice
Title: Re: fhDOOM (modernized idTech4)
Post by: Arl on April 10, 2016, 04:31:33 PM
This is exiting, sadly I'm getting a black screen launching the .exe. Sounds and music are there, but the image is black.
Title: Re: fhDOOM (modernized idTech4)
Post by: eXistence on April 10, 2016, 04:56:41 PM
Please post your system spec (especially graphics vendor and driver version), console log (if available) or screenshots when you run into problems.
Just anything that might help to track the issue down :)
Title: Re: fhDOOM (modernized idTech4)
Post by: oneofthe8devilz on April 10, 2016, 05:38:27 PM
I got to spend more time testing fhDOOM and... holy shit, this is a wonderful shadowmapping implementation and it is blazing fast !

I have no idea what was causing the slowdown when I initially ran it for the first time on my machine but now after setting the cvars according to your cvar info at the github page this baby flies and looks super sexy...

The proving grounds for any Doom3 shadowmapping implementation IMO is the canteen/cafeteria scene at the "mars_city"1 intro level. It is a worst case scenario for shadowmapping since it has an external pointlight outside the room simulating sunlight and a bunch of other tricky pointlights, making it a pretty tough scene for shadowmapping (with all kinds of precision/bias/lightbleeding/artifacts issues) compared to the default stencil shadows (When I get to it I will create a comparison GIF putting all 3 currently to me available shadowmapping solutions, showcasing how each of them handles that scene).

And your implementation so far seems to work great with that scene.

Last week when I was browsing through the Doom3 engine code I noticed some unnecessary rendering code that all 3 shadowmapping implementations (including yours too) seem to be still using while I think it is still being a relic from the stencil shadow rendering era.

When Doom3 was being developed and later released some people noticed a rendering artifact called "polypopping/shadowpopping". And while you and trebor are now using shadowmapping instead of stencil shadows it still happens/appears in your engines (RBDOOM-3-BFG & fhDOOM).

Back in the days we found a nice scene (also located in the mars_city1 intro level) which very nicely replicates that popping issue and both your engines still produce it.

(http://www.scared-pixel-studios.com/public/images/d3/oot8d_fbfl.gif)

So the solution was simply to always force BackFaceLighting to get rid of it in your engines.
Title: Re: fhDOOM (modernized idTech4)
Post by: Arl on April 10, 2016, 06:11:55 PM
Quote from: eXistence on April 10, 2016, 04:56:41 PM
Please post your system spec (especially graphics vendor and driver version), console log (if available) or screenshots when you run into problems.
Just anything that might help to track the issue down :)


Sure, sorry for not saying it first:


i7-3770

ATI Radeon HD 5770 (Sapphire Vapor-x)
(Driver Packaging Version: 15.20.1062.1004-150803a1-187669C)
(Catalyst Version:   15.7.1)

RAM: 8 GB

I have no console log.
Title: Re: fhDOOM (modernized idTech4)
Post by: VGames on April 10, 2016, 09:30:34 PM
How extensive would this be to add to Sikkmod source?
Title: Re: fhDOOM (modernized idTech4)
Post by: Bladeghost on April 11, 2016, 01:54:38 AM
This is quite impressive, I like the sliders on the light editor.
I'll have to look into this more as it is very promising so far----- fhdoom 1.5.0 (alpha). 1405
I do however get one warning though...
WARNING: Check extension 'GL_EXT_shared_texture_palette': failed

still great to see this, I'm excited to see what else it can do. as I just learned about it.
Title: Re: fhDOOM (modernized idTech4)
Post by: trebor on April 11, 2016, 02:54:37 AM
Quote from: oneofthe8devilz on April 10, 2016, 05:38:27 PM
Back in the days we found a nice scene (also located in the mars_city1 intro level) which very nicely replicates that popping issue and both your engines still produce it.

(http://www.scared-pixel-studios.com/public/images/d3/oot8d_fbfl.gif)

So the solution was simply to always force BackFaceLighting to get rid of it in your engines.

I fixed this in my latest build.
Title: Re: fhDOOM (modernized idTech4)
Post by: oneofthe8devilz on April 11, 2016, 06:26:24 AM
Quote from: trebor on April 11, 2016, 02:54:37 AM
I fixed this in my latest build.

Oh okay... cool

@eXistence: I just notice that you haven't yet implemented shadowmapping for the third type of lights in Doom3 called parallel lights (first type = point lights and second type = projected lights). I use parallel lights to simulate sunlight in MCS (http://www.moddb.com/mods/mars-city-security) and I wonder if you plan on writing a shadowmapped version of them ?
Title: Re: fhDOOM (modernized idTech4)
Post by: The Happy Friar on April 11, 2016, 07:21:45 AM
I downloaded the source but haven't had a chance to compile yet.  I'm eager to get it going in Community 2015 & I'll throw Brandon Chung's D3 basic assets (http://blendogames.com/news/?p=844) setup at it, see if it works with that. 
Title: Re: fhDOOM (modernized idTech4)
Post by: eXistence on April 11, 2016, 10:24:41 AM
Quote from: oneofthe8devilz on April 10, 2016, 05:38:27 PM
When Doom3 was being developed and later released some people noticed a rendering artifact called "polypopping/shadowpopping". And while you and trebor are now using shadowmapping instead of stencil shadows it still happens/appears in your engines (RBDOOM-3-BFG & fhDOOM).

@oneofthe8devilz: i was aware of those artifacts, but i didn't looked into it yet, thx for hint :)

Quote from: Phobos Anomaly on April 10, 2016, 04:31:33 PM
This is exiting, sadly I'm getting a black screen launching the .exe. Sounds and music are there, but the image is black.

@Phobos Anomaly: HD 5770? Phew! Thats even older than my test card (HD 6950)... but the specs look fine.
This starts fhDOOM in a window, enables OpenGL debug message, dumps the console to console.txt and quits the game.
fhDOOM.exe +set r_mode 6 +set _fullscreen 0 +set r_glDebugOutput 2 +condump console.txt +quit
Please send me the console.txt file via pm.

Quote from: VGames on April 10, 2016, 09:30:34 PM
How extensive would this be to add to Sikkmod source?

@VGames: Hmmm, it's been a while since i had a closer look at sikkmod, but i think what you ask for is not even possible.

Here is why (correct me if i am wrong, or if i misunderstood your question):

1. sikkmod is a mod for Doom3. fhDOOM is a modernized Doom3 engine. Those are two very different things, you can not integrate an engine into a mod. For beeing just a mod sikkmod is very impressive, but fhDOOM does a lot of things that are not even remotely possible in a mod.
2. You may ask if its possible to do it the other way round: integrate sikkmod into fhDOOM. Thats not possible either. AFAIK sikkmod is based on a couple of very clever ARB2 shader hacks to achieve effects like POM and Bloom. In fhDOOM those ARB2 shaders are completely gone (i am going to remove the last remaining bits of ARB2/FF very soon). Getting rid of this old and deprecated stuff is one of the major goals for fhDOOM.

Quote from: Bladeghost on April 11, 2016, 01:54:38 AM
I do however get one warning though...
WARNING: Check extension 'GL_EXT_shared_texture_palette': failed

@Bladeghost : this warning is bogus, just ignore it. This extension is not even used and i will remove the check and its warning for the next release.

Quote from: oneofthe8devilz on April 11, 2016, 06:26:24 AM
@eXistence: I just notice that you haven't yet implemented shadowmapping for the third type of lights in Doom3 called parallel lights (first type = point lights and second type = projected lights). I use parallel lights to simulate sunlight in MCS (http://www.moddb.com/mods/mars-city-security) and I wonder if you plan on writing a shadowmapped version of them ?

@oneofthe8devilz: yep, shadow mapping for parallel/directional lights is not implemented yet (the issue is also noted on the github page), but its definitely on my ToDo list. Parallel lights are used very rarely in the original game, so priority is kind of low. My focus is currently AMD, but maybe i will look into parallel lights after that.
Title: Re: fhDOOM (modernized idTech4)
Post by: VGames on April 11, 2016, 10:57:23 AM
Understood. I'll just stick with trusty old Sikkmod. It requires more resources but it does the job. Thanks for replying. Nice work by the way.
Title: Re: fhDOOM (modernized idTech4)
Post by: aphexjh on April 11, 2016, 02:33:16 PM
Hi. Looks great. 1 issue, maybe someone knows the reason for it. I get a problem where the skybox (cube map) flickers to black. see images.

(https://2.bp.blogspot.com/-5qCf4JtcAnE/VwvssB7VYwI/AAAAAAAAA_k/8t8U3G-o7wkFaztxJpGsdrZdm5CYEkq5w/s400/shot00148.jpg)
(https://4.bp.blogspot.com/-FAeDPpQZNB0/VwvssDEoSuI/AAAAAAAAA_o/ciZ9h98Rcq0rrnbV_EoZTUZqbpKjbOsLA/s400/shot00150.jpg)
Title: Re: fhDOOM (modernized idTech4)
Post by: Arl on April 11, 2016, 05:01:46 PM
Quote from: eXistence on April 11, 2016, 10:24:41 AM@Phobos Anomaly: HD 5770? Phew! Thats even older than my test card (HD 6950)... but the specs look fine.
This starts fhDOOM in a window, enables OpenGL debug message, dumps the console to console.txt and quits the game.
fhDOOM.exe +set r_mode 6 +set _fullscreen 0 +set r_glDebugOutput 2 +condump console.txt +quit
Please send me the console.txt file via pm.


Yeah, my radeon is an ancient remaining of antique technology, but right now graphics cards are very expensive, so an update will have to wait... ... another ten years.


I'll send the .txt to you right now.
Title: Re: fhDOOM (modernized idTech4)
Post by: argoon on April 11, 2016, 06:15:44 PM
Holly shit!! I still didn't try it but from what the guys say it seams to work fine for the most part, so congrates man!
And a QT based GUI engine?! Does this mean i can use QT designer to do GUI's?
Title: Re: fhDOOM (modernized idTech4)
Post by: romulus_ut3 on April 12, 2016, 04:59:32 AM
Runs like shit on AMD cards as always. The Soft Shadow, specially.
Title: Re: fhDOOM (modernized idTech4)
Post by: trebor on April 12, 2016, 05:02:02 AM
Quote from: romulus_ut3 on April 12, 2016, 04:59:32 AM
Runs like shit on AMD cards as always. The Soft Shadow, specially.

I'm somewhat glad to hear that :P
Title: Re: fhDOOM (modernized idTech4)
Post by: argoon on April 12, 2016, 08:40:02 AM
Quote from: romulus_ut3 on April 12, 2016, 04:59:32 AM
Runs like shit on AMD cards as always. The Soft Shadow, specially.

I'm on AMD and it does run more slowly when using shadow maps, that is somewhat expected because stencil shadows are faster by design, but even so, reading the eXistence (fhDOOM) engine docs seams it was tested on Nvidia cards only, i'm sure with some more tests on AMD we can help eXistance improve things. 

Quote from: trebor on April 12, 2016, 05:02:02 AM
I'm somewhat glad to hear that :P

Why?  :(


eXistence I will be glad to beta test for you if you want, my GPU is a R9 270X GPU.


Made some Searching about why AMD is slower on OpenGL compared to Nvidia and this came up, trebor is this accurate?

Quote... to put things simply, deferred contexts and command lists are not mandatory. AMD have specifically chosen not to use it in their driver. The drawback is significantly higher CPU overhead is observed, which heavily chokes the GPU(s) in CPU intensive applications. However, the positives from this is that you get a simple and stable driver which can work with almost any newly released game without compatibility issues and the need for specific driver tweaks. It also gives consistent performance in most games across the board, even if that performance is relatively low. Hence why you can run pretty much any Indie game on an AMD card without a "not supported" error message. In contrast to Nvidia drivers, each game requires driver tweaks for that game to actually remain stable. This is a lot of work for the driver team, but at least you are getting the performance boosts from the multi rendering capabilities of Direct-X 11. I would not be surprised if AMD chose compatibility over performance to either reduce staff workload, or because the driver team don't have the ability to compile a fully stable driver which uses such features discussed.

AMD have shown promise in the past with their CPU overhead issues with "Sid Meier's Civilization Beyond Earth", whereby they worked closely with the developer to ensure the game used good API optimization methods for enhanced CPU performance. AMD also enabled command list support (such a rare moment) for this title which allowed proper usage on all threads.

QuoteThat's to do with DX11 overhead, we aren't talking about that, nor do we have an issue with it. it's the OpenGL overhead which is shocking on AMD cards as they don't support Multithreaded OpenGL, where Nvidia does.

eXistance do you know about this?

https://community.amd.com/thread/194895 (https://community.amd.com/thread/194895)
Title: Re: fhDOOM (modernized idTech4)
Post by: romulus_ut3 on April 12, 2016, 09:43:50 AM
It even runs like shit on AMD cards with the "Hard" shadows as well at certain places, like the plasma beam place at Alphalabs1.
Title: Re: fhDOOM (modernized idTech4)
Post by: oneofthe8devilz on April 12, 2016, 11:04:41 AM
Quote from: romulus_ut3 on April 12, 2016, 09:43:50 AM
It even runs like shit on AMD cards with the "Hard" shadows as well at certain places, like the plasma beam place at Alphalabs1.

Could you try executing an fhdoom.cfg (with "exec fhdoom.cfg") containing the follwing values:

seta r_shadows "2"
seta r_shading "0"
seta r_pomEnabled "0"
seta r_smQuality "0"


Also eventually restart fhDOOM after executing the cfg file and let us know if that changes your bad perfomance.
Title: Re: fhDOOM (modernized idTech4)
Post by: romulus_ut3 on April 12, 2016, 02:28:56 PM
Quote from: oneofthe8devilz on April 12, 2016, 11:04:41 AM
Quote from: romulus_ut3 on April 12, 2016, 09:43:50 AM
It even runs like shit on AMD cards with the "Hard" shadows as well at certain places, like the plasma beam place at Alphalabs1.

Could you try executing an fhdoom.cfg (with "exec fhdoom.cfg") containing the follwing values:

seta r_shadows "2"
seta r_shading "0"
seta r_pomEnabled "0"
seta r_smQuality "0"


Also eventually restart fhDOOM after executing the cfg file and let us know if that changes your bad perfomance.

No improvements whatsoever. What executing these cvars does is make the graphics worse.
Title: Re: fhDOOM (modernized idTech4)
Post by: eXistence on April 12, 2016, 03:59:35 PM

Quote from: aphexjh on April 11, 2016, 02:33:16 PM
Hi. Looks great. 1 issue, maybe someone knows the reason for it. I get a problem where the skybox (cube map) flickers to black. see images.

@aphexjh : what are your system specs? Do you have a savegame or a minimal map that demonstrates the problem?

Quote from: argoon on April 11, 2016, 06:15:44 PM
Holly shit!! I still didn't try it but from what the guys say it seams to work fine for the most part, so congrates man!
And a QT based GUI engine?! Does this mean i can use QT designer to do GUI's?

@argoon : Probably yes... i am not 100% sure about how to use the custom widgets in the designer (i did the light editor manually), but it should be possible. The light editor is meant to be some kind of example: it interacts with the editor and game, it lists some Decls from the game and has a little rendering preview. Based on that, you could do more complex GUI tools.

Quote from: romulus_ut3 on April 12, 2016, 09:43:50 AM
It even runs like shit on AMD cards with the "Hard" shadows as well at certain places, like the plasma beam place at Alphalabs1.

@romulus_ut3 : I just got my AMD graphics card for debugging and testing and i have to admit, it runs shockingly bad on AMD. Besides some rendering issues that i still need to solve, the performance is very bad in general (compared to the original game). Shadow mapping has nothing to do with this. I am working on this, but since i am doing this in my spare time, don't expect a "quick fix" for it.

I cannot emphasise strongly enough, this is just a very early alpha version and is not (yet) meant to be used in more serious projects. I originally hoped for some feedback from users with a modern Intel GPU (to clarify whether some of the rendering issues are an AMD-only problem, or if it just happen to work on nVidia). My ultimate goal is to modernize the engine (to make implementing new feature like Qt-based tools and soft shadows easier). Porting Doom3 to modern OpenGL is a lot more than just rewriting a couple of shaders with GLSL. Doom3 is essentially a fixed-function engine. Obviously there are some shaders: The interaction shader is quite important and there are a couple of special effect shaders, but that's it. Everything else is fixed-function:


Not to forget all the resource management (geometry and textures). Changing all this to modern OpenGL means ripping out a lot of old and battle-tested code, and replacing it with new code. That new code introduces new bugs, new performance pitfalls, new incompatibilities with drivers or hardware. Working all this out will take some time. In the mean time (or if you don't like it at all), just stay with your current Doom engine. No problem :)
Title: Re: fhDOOM (modernized idTech4)
Post by: motorsep on April 12, 2016, 05:09:08 PM
Quote from: eXistence on April 12, 2016, 03:59:35 PM
Not to forget all the resource management (geometry and textures). Changing all this to modern OpenGL means ripping out a lot of old and battle-tested code, and replacing it with new code. That new code introduces new bugs, new performance pitfalls, new incompatibilities with drivers or hardware. Working all this out will take some time. In the mean time (or if you don't like it at all), just stay with your current Doom engine. No problem :)

So, why didn't you go with BFG engine instead ?
Title: Re: fhDOOM (modernized idTech4)
Post by: Arl on April 12, 2016, 07:15:43 PM
I don't know why, but today I tried opening fhdoom again and it worked... ...weird.

Anyways, I have to say that I also have bad performance. At the beginning it was all okay, but when I entered the scan room in mars city my fps dropped significantly from that point on. Not even sikkmod with enhanced textures and bla bla bla impacted this bad on my fps.

Beyond that, this is exiting, soft particles looked great and what you are planing to do in the future is also very promising, keep up the good work.
Title: Re: fhDOOM (modernized idTech4)
Post by: argoon on April 12, 2016, 07:55:04 PM
Quote from: romulus_ut3 on April 12, 2016, 02:28:56 PM
Quote from: oneofthe8devilz on April 12, 2016, 11:04:41 AM
Quote from: romulus_ut3 on April 12, 2016, 09:43:50 AM
It even runs like shit on AMD cards with the "Hard" shadows as well at certain places, like the plasma beam place at Alphalabs1.

Could you try executing an fhdoom.cfg (with "exec fhdoom.cfg") containing the follwing values:

seta r_shadows "2"
seta r_shading "0"
seta r_pomEnabled "0"
seta r_smQuality "0"


Also eventually restart fhDOOM after executing the cfg file and let us know if that changes your bad perfomance.

No improvements whatsoever. What executing these cvars does is make the graphics worse.

I'm sure that was what he wanted, he was trying to see if the shadow mapping was indeed the problem by removing all the other effects.

I also used it and I saw a clear bump in performance but that was expected with low graphics but i still add drop's from 63fps down into low 20fps's, i know is not optimized eXistance so don't think i'm critiquing you. ;)

Btw i add one strange performance problem, when i looked into a specific door with a broken surface GUI(where you get the blue key before passing trough the infirmary) and nothing else in view, my fps's went from 63 down to 18fps, if looked to the right or left where plenty more stuff was in view, fps's went up again to 63, even more strange fact is that, at first i though it could be the game rendering what was behind the door, but that particular door was also next to a window glass, where you could see all what was behind the door, if you looked trough the window, fps's would jump to ~45fps, if you put the door in your view the fps's would go down to ~20, could it be the surface gui causing problems?   
Title: Re: fhDOOM (modernized idTech4)
Post by: eXistence on April 13, 2016, 04:37:09 AM
Quote from: motorsep on April 12, 2016, 05:09:08 PM
Quote from: eXistence on April 12, 2016, 03:59:35 PM
Not to forget all the resource management (geometry and textures). Changing all this to modern OpenGL means ripping out a lot of old and battle-tested code, and replacing it with new code. That new code introduces new bugs, new performance pitfalls, new incompatibilities with drivers or hardware. Working all this out will take some time. In the mean time (or if you don't like it at all), just stay with your current Doom engine. No problem :)

So, why didn't you go with BFG engine instead ?

id software put a lot of effort and professional experience into the BFG edition and as far as i know trebor is doing an amazing job implementing new features for it.
Competing and catching up with that is not very likely for me, but that was never my intention.

Just like mentioned in my first post, i started to work on it because i was just curious how certain things were done and wanted to explore the code.
I chose vanilla Doom3 because i was familiar with it (did a lot of mapping and modeling in the early days), it had all the tools at hand and it was very easy and interesting to re-visit the stuff i did ten or twelve years ago.
Releasing it for others to use was not even planned at that point.

Just about a couple of weeks ago i stumbled across these forums. I noticed a few threads asking for a BFG-like shader system for vanilla Doom3, so i thought what i was doing might be interesting for others as well.
If no one is interested in it (for whatever reasons), that's totally fine. Staying with the original engine or with the BFG edition is a very reasonable choice.
Title: Re: fhDOOM (modernized idTech4)
Post by: motorsep on April 13, 2016, 08:23:12 AM
Fair 'nuff
Title: Re: fhDOOM (modernized idTech4)
Post by: oneofthe8devilz on April 13, 2016, 11:42:30 AM
Quote from: motorsep on April 13, 2016, 08:23:12 AM
Fair 'nuff

Man are we relieved that you find eXistence's explanation for why he chose to stick with the Doom 1.3.1 build "Fair 'nuff". God forbid if you hadn't approved it! ;D
Title: Re: fhDOOM (modernized idTech4)
Post by: SteveL on April 14, 2016, 12:19:07 PM
Quote from: eXistence on April 11, 2016, 10:24:41 AM
yep, shadow mapping for parallel/directional lights is not implemented yet (the issue is also noted on the github page), but its definitely on my ToDo list. Parallel lights are used very rarely in the original game, so priority is kind of low.
Parallel lights might not be hard for you to support. They are just omni lights with the light origin moved 100000x further away from the centre of the light volume than where the mapper put it. The hack to turn an omni light into a parallel one is in tr_lightrun.cpp R_DeriveLightData

Great work. I've been exploring the idTech4 vanilla engine on and off for the last 18 months working on TheDarkMod. I implemented soft particles in ARB (ugh) but have been experimenting with glsl in the engine for other effects. I'll be studying your work :)
Title: Re: fhDOOM (modernized idTech4)
Post by: oneofthe8devilz on April 14, 2016, 01:12:54 PM
Maybe reading through trebor's RBDOOM-3-BFG source could speed up that process as he already has a working solution for parallel lights.

I didn't yet get to test the latest RBDOOM-3-BFG build but do the actual origin coordinates of the parallel light, relative to the geometry it illuminates still influence the quality of shadows generated ?

Title: Re: fhDOOM (modernized idTech4)
Post by: SteveL on April 14, 2016, 01:28:44 PM
Quote from: oneofthe8devilz on April 14, 2016, 01:12:54 PM
Maybe reading through trebor's RBDOOM-3-BFG source could speed up that process as he already has a working solution for parallel lights.

I didn't yet get to test the latest RBDOOM-3-BFG build but do the actual origin coordinates of the parallel light, relative to the geometry it illuminates still influence the quality of shadows generated ?

Cool I just had a look at RBDOOM-3-BFG and it still has the same 100000x technique in there. But my point was that if you've solved the problem for omni lights, you've already solved it for parallel too. You just need to increase your penumbra spread for those lights at the same time, if your shadow technique uses light origin to calculate penumbra spread.

EDIT: Hmm maybe not true for shadow maps come to think of it. I've not messed with them, but I reckon you'd need to set a special resolution or frustrum at least to generate a map from that "distance"
Title: Re: fhDOOM (modernized idTech4)
Post by: vladdrak on April 15, 2016, 11:32:47 AM
Quote from: The Happy Friar on April 11, 2016, 07:21:45 AM
I downloaded the source but haven't had a chance to compile yet.  I'm eager to get it going in Community 2015 & I'll throw Brandon Chung's D3 basic assets (http://blendogames.com/news/?p=844) setup at it, see if it works with that.
just tried the starter kit with
- dhewm3 binaries
freshly compiled
- iodoom3
- fhdoom

all crashed at startup.

here's fhdoom:

fhDOOM 1.5.0 (alpha).1406 win-x86 Apr 15 2016 17:25:44
3392 MHz Intel CPU with MMX & SSE & SSE2 & SSE3 & HTT
16352 MB System Memory
1024 MB Video Memory
Winsock Initialized
Found interface: {99403915-59F4-419E-B9F6-2776D281EDB8} Qualcomm Atheros AR8161 PCI-E Gigabit Ethernet Controller (NDIS 6.30) - 192.168.0.11/255.255.255.0
Sys_InitNetworking: adding loopback interface
doom using MMX & SSE & SSE2 & SSE3 for SIMD processing
enabled Flush-To-Zero mode
enabled Denormals-Are-Zero mode
------ Initializing File System ------
Current search path:
d:\SANDBOX\DOOM3\sk/base
game DLL: 0x0 in pak: 0x0
Addon pk4s:
file system initialized.
--------------------------------------
----- Initializing Decls -----
------------------------------
------- Initializing renderSystem --------
renderSystem initialized.
--------------------------------------
WARNING: Unknown string id #str_04344
WARNING: Couldn't load image: textures/gui/black
WARNING: Couldn't load image: textures/gui/black
Couldn't open journal files
WARNING: Unknown string id #str_04345
couldn't exec editor.cfg
execing default.cfg
couldn't exec DoomConfig.cfg
couldn't exec autoexec.cfg
WARNING: Unknown string id #str_04346
----- Initializing Sound System ------
sound system initialized.
--------------------------------------
WARNING: Unknown string id #str_04347
WARNING: Unknown string id #str_04348
----- R_InitOpenGL -----
Initializing OpenGL subsystem
...registered window class
...registered fake window class
...calling CDS: ok
...created window @ 0,0 (1024x768)
Initializing OpenGL driver
...getting DC: succeeded
...PIXELFORMAT 10 selected
...creating GL legacy context: succeeded
...making legacy context current: succeeded
...initializing GL extensions (GLEW): succeeded
...creating GL core profile context: succeeded
...making core profile context current: succeeded
...deleting old GL legacy context...initializing GL extensions (GLEW): succeeded

------- Input Initialization -------
Initializing DirectInput...
mouse: DirectInput initialized.
keyboard: DirectInput initialized.
------------------------------------
sound: STEREO
Check extension 'GL_ARB_multitexture': OK
Check extension 'GL_ARB_texture_cube_map': OK
Check extension 'GL_ARB_texture_env_dot3': OK
Check extension 'GL_ARB_texture_env_add': OK
Check extension 'GL_ARB_texture_non_power_of_two': OK
Check extension 'GL_ARB_texture_compression': OK
Check extension 'GL_EXT_texture_compression_s3tc': OK
Check extension 'GL_EXT_texture_filter_anisotropic': OK
   maxTextureAnisotropy: 16.000000
Check extension 'GL_EXT_depth_bounds_test': OK

GL_VENDOR: NVIDIA Corporation
GL_RENDERER: GeForce GTX 560 Ti/PCIe/SSE2
GL_VERSION: 4.3.0 NVIDIA 364.72
GL_MAX_TEXTURE_SIZE: 16384
GL_MAX_TEXTURE_UNITS_ARB: 4
GL_MAX_TEXTURE_COORDS_ARB: 8
GL_MAX_TEXTURE_IMAGE_UNITS_ARB: 32

PIXELFORMAT: color(32-bits) Z(24-bit) stencil(8-bits)
MODE: 5, 1024 x 768 fullscreen hz:N/A
CPU: Intel CPU with MMX & SSE & SSE2 & SSE3 & HTT
-------
glFinish not forced
swapInterval not forced
load vertex shader glsl/fogLight.vp
: File not found
WARNING: failed to load GLSL vertex shader: fogLight.vp
load vertex shader glsl/blendLight.vp
: File not found
WARNING: failed to load GLSL vertex shader: blendLight.vp
load vertex shader glsl/shadow.vp
: File not found
WARNING: failed to load GLSL vertex shader: shadow.vp
load vertex shader glsl/depth.vp
: File not found
WARNING: failed to load GLSL vertex shader: depth.vp
load vertex shader glsl/shadowmap.vp
: File not found
WARNING: failed to load GLSL vertex shader: shadowmap.vp
load vertex shader glsl/default.vp
: File not found
WARNING: failed to load GLSL vertex shader: default.vp
load vertex shader glsl/depthblend.vp
: File not found
WARNING: failed to load GLSL vertex shader: depthblend.vp
load vertex shader glsl/skybox.vp
: File not found
WARNING: failed to load GLSL vertex shader: skybox.vp
load vertex shader glsl/bumpyenv.vp
: File not found
WARNING: failed to load GLSL vertex shader: bumpyenv.vp
load vertex shader glsl/interaction.vp
: File not found
WARNING: failed to load GLSL vertex shader: interaction.vp
load vertex shader glsl/vertexcolor.vp
: File not found
WARNING: failed to load GLSL vertex shader: vertexcolor.vp
load vertex shader glsl/flatcolor.vp
: File not found
WARNING: failed to load GLSL vertex shader: flatcolor.vp
load vertex shader glsl/intensity.vp
: File not found
WARNING: failed to load GLSL vertex shader: intensity.vp
load vertex shader glsl/fogLight.vp
: File not found
WARNING: failed to load GLSL vertex shader: fogLight.vp
load vertex shader glsl/blendLight.vp
: File not found
WARNING: failed to load GLSL vertex shader: blendLight.vp
load vertex shader glsl/shadow.vp
: File not found
WARNING: failed to load GLSL vertex shader: shadow.vp
load vertex shader glsl/depth.vp
: File not found
WARNING: failed to load GLSL vertex shader: depth.vp
load vertex shader glsl/shadowmap.vp
: File not found
WARNING: failed to load GLSL vertex shader: shadowmap.vp
load vertex shader glsl/default.vp
: File not found
WARNING: failed to load GLSL vertex shader: default.vp
load vertex shader glsl/depthblend.vp
: File not found
WARNING: failed to load GLSL vertex shader: depthblend.vp
load vertex shader glsl/skybox.vp
: File not found
WARNING: failed to load GLSL vertex shader: skybox.vp
load vertex shader glsl/bumpyenv.vp
: File not found
WARNING: failed to load GLSL vertex shader: bumpyenv.vp
load vertex shader glsl/interaction.vp
: File not found
WARNING: failed to load GLSL vertex shader: interaction.vp
load vertex shader glsl/vertexcolor.vp
: File not found
WARNING: failed to load GLSL vertex shader: vertexcolor.vp
load vertex shader glsl/flatcolor.vp
: File not found
WARNING: failed to load GLSL vertex shader: flatcolor.vp
load vertex shader glsl/intensity.vp
: File not found
WARNING: failed to load GLSL vertex shader: intensity.vp
WARNING: SetDeviceGammaRamp failed.
WARNING: Couldn't load image: textures/gui/black
WARNING: Couldn't load image: textures/gui/black
WARNING: Unknown string id #str_04343
WARNING: Unknown string id #str_04349
WARNING: Couldn't load image: ui/assets/guicursor_arrow
WARNING: Couldn't load image: ui/assets/guicursor_hand
WARNING: Couldn't load image: ui/assets/scrollbarh
WARNING: Couldn't load image: ui/assets/scrollbarv
WARNING: Couldn't load image: ui/assets/scrollbar_thumb
WARNING: Couldn't load image: ui/assets/scrollbar_right
WARNING: Couldn't load image: ui/assets/scrollbar_left
WARNING: Couldn't load image: ui/assets/scrollbar_up
WARNING: Couldn't load image: ui/assets/scrollbar_down
WARNING: Unknown string id #str_04350
DLL file name: fhGame-x86.dll
look for DLL next to executable: D:\SANDBOX\DOOM3\sk/fhGame-x86.dll
game using MMX & SSE & SSE2 & SSE3 for SIMD processing
enabled Flush-To-Zero mode
enabled Denormals-Are-Zero mode
--------- Initializing Game ----------
gamename: baseDOOM-1
gamedate: Apr 15 2016
Initializing event system
...473 event definitions
Initializing class hierarchy
...142 classes, 191092 bytes for event callbacks
Initializing scripts
--------- Game Map Shutdown ----------
--------------------------------------
********************
ERROR: Error: file script\doom_events.script, line 49: Unknown event 'setGui'


********************
Error during initialization
Shutting down OpenGL subsystem
...wglMakeCurrent( NULL, NULL ): success
...deleting GL context: success
...releasing DC: success
...destroying window
...resetting display


plz post your results/fixes on the issue if you try it, thx.
Title: Re: fhDOOM (modernized idTech4)
Post by: vladdrak on April 15, 2016, 11:51:55 AM
eXistence: fhdoom could be the new de facto solution for idtech4-based projects, but i really like openal. don't you consider forking/moving yr changes to dhewm3 instead of vanilla d3?
Title: Re: fhDOOM (modernized idTech4)
Post by: argoon on April 15, 2016, 12:53:52 PM
Quote from: vladdrak on April 15, 2016, 11:51:55 AM
eXistence: fhdoom could be the new de facto solution for idtech4-based projects, but i really like openal. don't you consider forking/moving yr changes to dhewm3 instead of vanilla d3?

Don't know if you are aware but Doom 3 supports OpenAL natively, ever since it came or are you saying," i like OpenAL soft"? Because there's a diference, Doom 3 comes with Creative's hardware accelerated OpenAL (with EFX and EAX 4.0 support).
Title: Re: fhDOOM (modernized idTech4)
Post by: caedes on April 15, 2016, 03:58:33 PM
Quote from: argoon on April 15, 2016, 12:53:52 PM
Quote from: vladdrak on April 15, 2016, 11:51:55 AM
eXistence: fhdoom could be the new de facto solution for idtech4-based projects, but i really like openal. don't you consider forking/moving yr changes to dhewm3 instead of vanilla d3?

Don't know if you are aware but Doom 3 supports OpenAL natively, ever since it came or are you saying," i like OpenAL soft"? Because there's a diference, Doom 3 comes with Creative's hardware accelerated OpenAL (with EFX and EAX 4.0 support).
only on windows and you only get the EAX stuff with creative cards, in dhewm3 you get it everywhere with all hardware
Title: Re: fhDOOM (modernized idTech4)
Post by: argoon on April 16, 2016, 06:35:17 PM
Quote from: caedes on April 15, 2016, 03:58:33 PM
Quote from: argoon on April 15, 2016, 12:53:52 PM
Quote from: vladdrak on April 15, 2016, 11:51:55 AM
eXistence: fhdoom could be the new de facto solution for idtech4-based projects, but i really like openal. don't you consider forking/moving yr changes to dhewm3 instead of vanilla d3?

Don't know if you are aware but Doom 3 supports OpenAL natively, ever since it came or are you saying," i like OpenAL soft"? Because there's a diference, Doom 3 comes with Creative's hardware accelerated OpenAL (with EFX and EAX 4.0 support).
only on windows and you only get the EAX stuff with creative cards, in dhewm3 you get it everywhere with all hardware

Ah ok i stand corrected.
Title: Re: fhDOOM (modernized idTech4)
Post by: nbohr1more on April 17, 2016, 10:57:01 AM
Extra food for thought:

Pat Raynor has a hybrid Vanilla\BFG Doom 3 here:

https://github.com/raynorpat/Doom3

Relevators vanilla Doom 3 with Depth Bounds and BFG fixes:

https://github.com/revelator/Revelation

Perpixel's Oculus Rift branch:

https://github.com/Perpixel/Doom3

Sikkpin Feedback. Prey style shader system:

https://github.com/RobertBeckebans/Sikkpin-Feedback
Title: Re: fhDOOM (modernized idTech4)
Post by: eXistence on April 21, 2016, 02:21:45 AM
@oneofthe8devilz
@SteveL


Shadow mapping for parallel lights is on my ToDo list and i am aware of trebors implementation.
Right now i am focussed on performance (especially on AMD), cleaning up a lot of things and fixing a couple of bugs.

@argoon

No, i will not switch to dhewm3 any time soon.
I tinkered with the idea of updating the sound engine as well, but it's very low priority right now.


@nbohr1more

Thx for the hints! I remember some GLSL-related work on Doom3 from Pat Raynor a few years(?) ago, but totally forgot about it.
Title: Re: fhDOOM (modernized idTech4)
Post by: argoon on April 21, 2016, 06:36:47 PM
Quote from: eXistence on April 21, 2016, 02:21:45 AM

@argoon

No, i will not switch to dhewm3 any time soon.
I tinkered with the idea of updating the sound engine as well, but it's very low priority right now.


Ok nice to know, btw i was not asking you to go to dhewm3 i was responding to vladdrak .   ;D   :)

btw trying to compile your source code with VS2013 and i'm guetting this error 3 times
QuoteError   1   error LNK1104: cannot open file 'nafxcwd.lib'   M:\fhDOOM-master\build\msvc2013-x86\neo\TypeInfo\LINK   TypeInfo
i have VS2015 and the windows SDK 8.1 installed, i'm a noob at this so sorry if is something obvious.

Edit: it seams i'm dumb i didn't installed the MBCS-Addon for VS 2013 now it works.
Title: Re: fhDOOM (modernized idTech4)
Post by: eXistence on June 27, 2016, 04:13:53 PM
Hi,

I worked on a couple of things over the last weeks (mainly related to AMD and performance)
and i think it's time for a new release for those who are interested.

download: http://www.facinghell.com/fhdoom/fhDOOM-1.5.1-1413.zip (http://www.facinghell.com/fhdoom/fhDOOM-1.5.1-1413.zip)

changes:
I did all the development with an AMD Radeon HD6950 (CPU: Intel Core2Quad 2.8GHz). The AMD Gaming Evolved App ("Raptr"?) causes a significant performance drop, so i recommend you disable that before starting fhDOOM.
At highest quality settings, there are still some scenes where framerate drops below 30FPS ;( Changing shadow quality to medium (via main menu or r_smLodBias 1) improves the situation a lot. Can someone with a modern AMD card verify this?

There are still some things i would like to implement to improve performance, but right now i am a bit tired of it. There are a couple of new features i want to test out and few more content-related things i want to try out, before eventually getting back to performance.

Feedback appreciated :)
Title: Re: fhDOOM (modernized idTech4)
Post by: motorsep on June 27, 2016, 05:31:05 PM
Nice list!

You should port some of the features and tools from Storm Engine 2 to your project ! :)
Title: Re: fhDOOM (modernized idTech4)
Post by: 0x29a on June 28, 2016, 06:46:33 AM
There's one thing that particulary bothers me...
While your engine is great from what I've seen, and it yealds tons of potential, folks won't use it without... SikkMod. Sikk's special effects (motion blur, screen frost, etc. gameplay modifications aside, not important) had become something like an industry standard in D3 modding community.
Is it really that hard to port SM into your engine? Or making it backwards-compatible?
Thanks in advance for reply!
P.S. I'd love to use your engine, especially because of the performance improvement, but some of Sikk's features are important for the overall gameplay in my mod, so - wether I like it or not - I'm stuck with 1.3.1 GPL version. 
Title: Re: fhDOOM (modernized idTech4)
Post by: bitterman on June 28, 2016, 07:13:30 AM
Raynor's code don't has .sln and (as I think) still unfinished. Sadly.

But now I think this idea (D3 plus GLSL) is overdue.

Only few things may discourage to use BFG code (SWF, resources, etc).

And now with help of few mens (trebor, motorsep and others) these problems are almost resolved.

Since the advent of guidelines for working with these things the potential of new code is open for modders.

Sorry for little offtop.

Title: Re: fhDOOM (modernized idTech4)
Post by: EoceneMiacid on June 28, 2016, 09:25:46 AM
Hmm.

I'd love to try this.

I'm trying to compile it for Linux. According to the readme, the scons command must be run in the /neo folder, but that returns "scons: *** No SConstruct file found."

The project doesn't seem to contain any SConstruct file when I look for it. The closest I could find was a subdirectory /neo/sys/scons, which contains a bunch of SConscript files.

Has this file been omitted or am I just an idiot?
Title: Re: fhDOOM (modernized idTech4)
Post by: eXistence on June 29, 2016, 06:08:40 AM
@0x29a(and @bitterman to some extend):

It's not possible to integrate SikkMod's (ARB2-based) interaction shaders into (GLSL-based) fhDOOM, you simply cannot mix these things. Some of SikkMod's (ARB2-based) post processing shaders might be technically capable of being integrated into fhDOOM, but i am not sure about that. Even if it is possible, i would need to put an uncertain amount of extra work into fhDOOM for that, drop OpenGL core profile and probably apply some changes to SikkMod's shaders. I simply don't want to take that route, especially because all those changes have to be maintained and i fear that this kind of backward compatibility hinders future changes.

Playing with a couple of new rendering features is next on my ToDo list and some of those features are implemented in SikkMod as well. I already did something like that with Parallax Occlusion Mapping. POM in fhDOOM is not ported from SikkMod, it's the same feature just implemented from scratch in a more modern way (but it suffers from the exact same problems, that's why it's off by default and the option to enable it is not exposed in the game's main menu). A future release of fhDOOM might suit your needs better, but don't count on it. If you need SikkMod you are stuck with vanilla Doom3 (or dhwem3?).

fhDOOM was never meant to replace one of the existing engines or revive Doom3 modding or something like that. I never cared very much about these things (i even dropped support for mods of the original game, that alone is a huge disadvantage compared to vanilla 1.3.1). fhDOOM is tailored to my particular needs and interests.

@EoceneMiacid:

Linux is supported, but since i am currently focussed on Windows, the linux build is not maintained very well and the game is not tested regularly on linux. I did a quick test on a fresh Xubuntu 16.04 (64bit) machine yesterday and it compiles and runs fine (at least with proprietary nVidia drivers, not sure about the different AMD drivers). See http://www.facinghell.com/fhdoom/fhDOOM-1.5.1-1413-linux.png Keep in mind, fhDOOM is still 32bit only at this point. So if you are on a 64bit machine, you need to install 32bit versions of some libraries. Better linux support is on my ToDo list, but priority is very low.

Here is a crude little script that i use to install all dependencies on an ubuntu machine to compile fhDOOM:

#!/bin/sh
# installs required packages on Ubuntu to compile fhDOOM.
# most packages will install additional dependencies that are also required but are not explicitly listed here.

echo "installing basic stuff..."
sudo apt-get install git cmake g++

echo "installing dev packages..."
sudo apt-get install freeglut3-dev libalut-dev libasound2-dev

MACHINE_TYPE=`uname -m`
echo "machine type:"${MACHINE_TYPE}
if [ "$MACHINE_TYPE" = "x86_64" ]; then
echo "installing 32bit libraries..."
sudo apt-get install g++-multilib freeglut3-dev:i386 libalut-dev:i386 libasound2-dev:i386
fi
Title: Re: fhDOOM (modernized idTech4)
Post by: EoceneMiacid on June 29, 2016, 07:53:46 AM
Hi,

Thanks for your help. Cmake works now, and I have installed all dependencies except this one:

g++-multilib :
Depends: gcc-multilib (>= 4:5.3.1-1ubuntu1) but it is not going to be installed
Depends: g++-5-multilib (>= 5.3.1-3~) but it is not going to be installed

Of course trying to run make regardless returns a whole lot of errors.

If the dependency problem isn't easy to fix, I'm going to have to wait until 64bit support for Linux has been added.

To be honest, I'm a bit miffed to read that you chose to deliberately withhold proper mod support, if I understand correctly. It's your project and it's up to you what you do with it (I guess I could fork the project but my programming skills aren't quite up to that level yet), but it kind of seems strange to me that you chose to implement a number of very attractive features and then remove a crucial one, especially since you're actively developing a mod project yourself.

The Doom 3 scene already is fragmented enough as it is, and various source ports taking it in different directions will only make it worse.









Title: Re: fhDOOM (modernized idTech4)
Post by: eXistence on June 29, 2016, 11:33:51 AM
I am not working on a mod project.
Mod support is still there and fully functional, you just can't load dll/so files that have been compiled for vanilla Doom3 1.3.1 (but thats for true for dhewm3 as well, afaik).

It's not the jack-of-all-trades-uber-idtech4 engine that some seem to expect. It's just a personal research and learning project, and i have said that many times.
Sorry, but that's the way it is. I am tired of explaining myself for that. Take it or leave it :)
Title: Re: fhDOOM (modernized idTech4)
Post by: EoceneMiacid on June 29, 2016, 12:19:50 PM
Hmmz, I ended up on the Facing Hell website which clearly states that somebody with both your real name and your nickname is the lead level designer for the project.

What are the odds huh ;)

Well, for now, I guess I have little choice but to leave it. Once again, you're free to spend your own free time as you want.

I'm honestly not trying to guilt-trip you here, but the lack of an industry standard Doom 3 source port across all OS's is at this point probably the largest obstacle to growing our numbers.

Title: Re: fhDOOM (modernized idTech4)
Post by: eXistence on June 29, 2016, 01:36:18 PM
Quote from: EoceneMiacid on June 29, 2016, 12:19:50 PM
Hmmz, I ended up on the Facing Hell website which clearly states that somebody with both your real name and your nickname is the lead level designer for the project.

What are the odds huh ;)

I might have known it. That project is dead since ~10 years or so, there is no work being done on it :)

Quote from: EoceneMiacid on June 29, 2016, 12:19:50 PM
Well, for now, I guess I have little choice but to leave it.
Thats very understandable and i am totally fine with it :)

Quote from: EoceneMiacid on June 29, 2016, 12:19:50 PM
I'm honestly not trying to guilt-trip you here, but the lack of an industry standard Doom 3 source port across all OS's is at this point probably the largest obstacle to growing our numbers.
I always thought of dhewm3 of beeing exactly that, since it stated on the github wiki: The goal of dhewm 3 is bring DOOM 3 with the help of SDL to all suitable platforms.
Title: Re: fhDOOM (modernized idTech4)
Post by: Bladeghost on June 29, 2016, 01:36:38 PM
@eXistence, I for one would like to thank you for sharing this, as it works well enough with my stand alone Phantasm mod. (not fully tested but works)
also I'd like to see what it can do for other projects as well. Again Thanks for sharing! I for one greatly appreciate it! as it offers some new possibilities in building projects with. Great Stuff!
Title: Re: fhDOOM (modernized idTech4)
Post by: EoceneMiacid on June 29, 2016, 02:50:13 PM
Quote from: eXistence on June 29, 2016, 01:36:18 PM

I always thought of dhewm3 of beeing exactly that, since it stated on the github wiki: The goal of dhewm 3 is bring DOOM 3 with the help of SDL to all suitable platforms.

It's definitely the closest thing we have to it so far. Dhewm3 is great, it works as advertised. I'm experiencing some glitches with dmap, something that doesn't seem to happen in id's official build, but that one is over 10 years old now and becomes increasingly difficult to run on modern systems.

However, until we get active mod developers to publish the source code of their library under the GPL, dhewm3 is currently only able to play two mods: Classic Doom and Denton mod. 'Soft' mods generally work of course, but typically not without a lot of hacking and fixing first.

That's really such a huge pain in the ass about Doom 3 modding - the precompiled C++ library aspect.

Title: Re: fhDOOM (modernized idTech4)
Post by: trebor on June 30, 2016, 07:41:36 AM
I also appreciate your efforts with fhDOOM even if you don't support mods. It is very nice to see new code and innovations in the id Tech family.
Title: Re: fhDOOM (modernized idTech4)
Post by: 0x29a on July 02, 2016, 08:01:19 AM
Quotedhewm3 is currently only able to play two mods: Classic Doom and Denton mod.

Well, I'm not sure about Classic Doom, but DentonMod brings lots of changes to the SDK:
- Changin projectile types
- Attaching particles to weapons
- Better dynamic damage zones
- Toggle weapons
- And some other things too, can't remember now...

I made this SDK pack from the combination of DentonMod and SikkMod a while ago, so I'm pretty certain of what I'm saying... DentonMod won't run without custom gamex86.dll/so, backed by custom doom_events.script. 
Title: Re: fhDOOM (modernized idTech4)
Post by: bkt on July 04, 2016, 04:42:25 PM
One thing worth noting about Sikkmod is that -- outside of the gameplay modifications -- is essentially a collection of post process effects.  If someone was to integrate the same effects into any branch at the engine level, it would be essentially the same. 

Something very useful that Sikk did was making sure that all of the variables for each effect were visible as cvar's.  He also implement multiple solutions for various effects (eg. Crysis SSAO vs HBAO or Tone mapping vs UE3/Cryengine 2 style LUT colorgrading).  In the case of working with him and a custom build of Sikkmod on my last mod, I was able to customize the visual style of the mod while balancing the quality of various effects for performance (eg. Bilinear DoF or Bokeh DoF).

The majority of the implementation of the various effects were simply standards available online that he'd managed to integrate in an intelligent (and versatile) way.

The custom version he developed with me for False Dawn had a number of very cool additions not available in Sikkmod V1.2 for D3.  Sadly he went MIA right before I completed the project and got the final source off him :(

Title: Re: fhDOOM (modernized idTech4)
Post by: oneofthe8devilz on July 06, 2016, 07:40:18 AM
The updated fhDoom version features a very solid and efficient shadowmapping solution. Delighted to see that you implemented parallel lights which work remarkably well with my outdoor test maps with good light bleeding and contact shadow results.

Noticed that the default Doom3 ambient lights seem to not render properly in fhDoom (having a directional shading instead of lighting up all geometry evenly) since I use huge ambient lights in my outdoor scenes as a very rough approximation of radiosity.

Title: Re: fhDOOM (modernized idTech4)
Post by: nbohr1more on July 06, 2016, 04:16:38 PM
Is the shading hard-coded to a direction or does it follow the light_center value?
Title: Re: fhDOOM (modernized idTech4)
Post by: motorsep on July 06, 2016, 04:56:46 PM
Quote from: nbohr1more on July 06, 2016, 04:16:38 PM
Is the shading hard-coded to a direction or does it follow the light_center value?

Good news is that you could probably port all the goodies directly to The Dark Mod!!!
Title: Re: fhDOOM (modernized idTech4)
Post by: nbohr1more on July 06, 2016, 05:38:47 PM
Yes, this is pretty ideal.

We'd need to covert a bunch of our custom ARB to GLSL but I believe SteveL is more comfortable with GLSL anyway.

This along with some of the work that Revelator has done with threading will be some nice improvements.

Still mostly looking forward to GPU Skinning and RGTC normal map compression though.
Title: Re: fhDOOM (modernized idTech4)
Post by: motorsep on July 06, 2016, 09:14:47 PM
Quote from: nbohr1more on July 06, 2016, 05:38:47 PM... and RGTC normal map compression though.

3Dc is the best.
Title: Re: fhDOOM (modernized idTech4)
Post by: nbohr1more on July 07, 2016, 10:19:11 AM
We had a prototype of LATC compression (3Dc for OpenGL) but Intel did not have driver support for it.
It might be that a 4.x profile driver from them includes it but then you basically need to do multiple profiles :(
Everyone has RGTC
Title: Re: fhDOOM (modernized idTech4)
Post by: EmoLevelDesigner on August 23, 2016, 11:27:53 AM
Soft shadows which take textures with transparent parts into account make the game look a lot more realistic and modern.

Do you plan to implement support of high frame rates? The game would be a lot more immersive if played at 144fps with motion blur.

I like it so far and look forward to newer version with more optimizations and bug fixes. For testing if everything in the port works properly I would recommend this map:
http://doom3.ru/news.php?id=1350
Link to download: https://disc.yandex.com/d/UWCr_8rinXwWf

I believe it would serve well as a stress test because it has a detailed open area with many shadows, buildings you can enter. Also while testing you can enjoy new innovative environment in Doom3 universe - artificial terrain carved by martian civilization. There are buildings, stations and cargo trucks of UAC origin you can enter, they have original architecture too, and challenging battles will push your skills of opposing the demons to the limits and beyond.
Title: Re: fhDOOM (modernized idTech4)
Post by: eXistence on August 26, 2016, 06:15:08 AM
Hi,

Quote from: EmoLevelDesigner on August 23, 2016, 11:27:53 AM
Do you plan to implement support of high frame rates? The game would be a lot more immersive if played at 144fps with motion blur.

60Hz is IMO just fine. Even DOOM (2016) which is a lot faster than Doom3 plays pretty nice with 60Hz.
I have currently no plans to implement motion blur.

Quote from: EmoLevelDesigner on August 23, 2016, 11:27:53 AM
I like it so far and look forward to newer version with more optimizations and bug fixes. For testing if everything in the port works properly I would recommend this map:
http://doom3.ru/news.php?id=1350
Link to download: https://disc.yandex.com/d/UWCr_8rinXwWf

I believe it would serve well as a stress test because it has a detailed open area with many shadows, buildings you can enter. Also while testing you can enjoy new innovative environment in Doom3 universe - artificial terrain carved by martian civilization. There are buildings, stations and cargo trucks of UAC origin you can enter, they have original architecture too, and challenging battles will push your skills of opposing the demons to the limits and beyond.

Thx for the suggestion, but i don't think this map qualifies as a test map.
* a lot of things are just bad for performance (even for original Doom3 and stencil shadows)
* it looks pretty amateurish
   * low-poly brush-based terrain
   * simple lighting
   * simple texturing
   * missing details in general
   The map has some pretty neat ideas and i really don't want to bash it, but it's just not on par with the maps from the original game.
* everything is russian? WTF? i don't undersand a single word of it...

I am focused on the original game. That beeing said, i have same ideas for a little demo map designed specifically for the improved engine.
Unfortunately my time is very limited right now, so progress on fhDOOM is slowed down at the moment ;(
Title: Re: fhDOOM (modernized idTech4)
Post by: EmoLevelDesigner on August 27, 2016, 06:34:31 AM
If a game supports 144Hz and motion blur it plays a lot better than just fine or pretty nice. It becomes like a window into another world. 144Hz together with motion blur eliminate immersion-breaking lights and fires that magically start to blink when you look around and fast moves that lose smoothess due to being too quick.
Title: Re: fhDOOM (modernized idTech4)
Post by: eXistence on August 29, 2016, 09:26:20 AM
Quote from: EmoLevelDesigner on August 27, 2016, 06:34:31 AM
If a game supports 144Hz and motion blur it plays a lot better than just fine or pretty nice. It becomes like a window into another world. 144Hz together with motion blur eliminate immersion-breaking lights and fires that magically start to blink when you look around and fast moves that lose smoothess due to being too quick.

144Hz is better than 60Hz, i won't argue that. As a test i already bumped the limit to 120* and it doesn't feel that different, so i still believe it's not worth it (for Doom3).
Hitting 60Hz on older hardware is hard enaugh and there are more interesting and more important things to do (for me as a dev and IMO for most users as well)

* the limit also affects other things like networking, so i don't want to release it that way.
Title: Re: fhDOOM (modernized idTech4)
Post by: motorsep on August 29, 2016, 09:59:29 AM
@EmoLevelDesigner

I think it's safe to say that if you want all modern visuals you might just play DOOM and use SnapMap to make new campaign :)

If you think about this, Doom 3 engine mods were released a long while back, and yet no one has made a decent game mod using those forks. End of era happened looooong time ago, unfortunately.

fhDOOM is a nice engine mod and I wish there were gameplay fixes along with rendering enhancements.

@eXistence

I provided caedes (dhewm3 maintainer/contributor) with our old fork of improved dhewm3. It has vehicle fixes / enhancements. StormEngine 2 has a lot of goodies, render-wise and gameplay wise. If you could merge those into fhDOOM, it would be really solid engine people should take advantage of and make some good mods.
Title: Re: fhDOOM (modernized idTech4)
Post by: bkt on August 30, 2016, 11:32:10 AM
To be honest, I'll take my engine mods simply as engine mods.  Bundling gameplay mods in just muddies the waters, especially if there aren't easy toggles to revert the game back to its original gameplay state.

One of my biggest issues with Sikkmod for example was the way that it modified so many small aspects of the game loop.  If I wanted to simply replay the game, or try a custom map, it was a pain to relive that same experience with added visual flare.

In saying that, I'm aware that I completely reworked a lot of Quake 4's features in my last Sikkmod powered release, but that was kind of the idea.

fhDoom sounds like it would be a great starting place for someone to either build a map, mod or just play through existing content with a nice coat of paint.
Title: Re: fhDOOM (modernized idTech4)
Post by: argoon on November 06, 2016, 10:02:30 PM
Hey eXistance if you are still around can you tell me if is possible to disable your new shadow maps by material or by script like we do with the old stencil shadows? It seams the noShadows global material keyword is ignored by shadow maps, i'm sure you did that so alpha tested materials on the vanilla maps could cast shadows but, i found on my testes with a custom grass/LOD system that a bunch of grass planes casting shadows is not good for performance.  :P

Thanks a bunch for your engine and help.
Title: Re: fhDOOM (modernized idTech4)
Post by: eXistence on November 09, 2016, 12:16:53 PM
Quote from: argoon on November 06, 2016, 10:02:30 PM
Hey eXistance if you are still around can you tell me if is possible to disable your new shadow maps by material or by script like we do with the old stencil shadows? It seams the noShadows global material keyword is ignored by shadow maps, i'm sure you did that so alpha tested materials on the vanilla maps could cast shadows but, i found on my testes with a custom grass/LOD system that a bunch of grass planes casting shadows is not good for performance.  :P

Yes, your assumption is correct: the noShadows material flag is usually* ignored on alphatested materials to enabled shadows. There is currently no way to enforce noShadows on materials. I will probably add support for something like force noShadows to the next release of fhDOOM to fix this.
Can you create a func_static from your grass planes? Setting the entity property "noshadows" to "1" should work fine.


*: there is a dirty little exception: if the material is alphatested, but is not two-sided and the name starts with "texture/decals", the noShadows flag works like before. I guess that won't help you very much...
Title: Re: fhDOOM (modernized idTech4)
Post by: argoon on November 10, 2016, 09:20:58 AM
Thanks, yes they are indeed func_statics never tried to force the no shadows by entity property, thanks for the tip. :)

About the texture/decal part it will indeed help because i can have a decal material/texture outside the decal folder and it would cast shadows without me knowing, now i know. :D

Thank you and continue the great work.
Title: Re: fhDOOM (modernized idTech4)
Post by: argoon on December 22, 2016, 08:57:05 AM
Hello it seams i'm having problems trying to compile fhdoom on VS2015 and i don't have VS2013 anymore, i have all the minimum required dependencies like so:

CMake 3.5
Windows 8.1 SDK

But i still get this errors:
Quote
Error   C1083   Cannot open include file: 'afxwin.h': No such file or directory   idlib   q:\fhdoom\work_folder\fhdoom-master\neo\tools\comafx\StdAfx.h   38

Error   LNK1104   cannot open file '..\idlib\Debug\idlib.lib'   fhGame-roe-x86   Q:\fhdoom\Work_folder\fhDOOM-master\build\msvc2015-x86\neo\d3xp\LINK   1

Error   LNK1104   cannot open file '..\idlib\Debug\idlib.lib'   fhGame-x86   Q:\fhdoom\Work_folder\fhDOOM-master\build\msvc2015-x86\neo\game\LINK   1

Error   C1083   Cannot open include file: 'afxwin.h': No such file or directory (compiling source file Q:\fhdoom\Work_folder\fhDOOM-master\neo\framework\File.cpp)   TypeInfo   q:\fhdoom\work_folder\fhdoom-master\neo\tools\comafx\StdAfx.h   38

Error   C1083   Cannot open include file: 'afxwin.h': No such file or directory (compiling source file Q:\fhdoom\Work_folder\fhDOOM-master\neo\framework\CVarSystem.cpp)   TypeInfo   q:\fhdoom\work_folder\fhdoom-master\neo\tools\comafx\StdAfx.h   38

Error   C1083   Cannot open include file: 'afxwin.h': No such file or directory (compiling source file Q:\fhdoom\Work_folder\fhDOOM-master\neo\framework\Unzip.cpp)   TypeInfo   q:\fhdoom\work_folder\fhdoom-master\neo\tools\comafx\StdAfx.h   38

Error   C1083   Cannot open include file: 'afxwin.h': No such file or directory (compiling source file Q:\fhdoom\Work_folder\fhDOOM-master\neo\TypeInfo\main.cpp)   TypeInfo   q:\fhdoom\work_folder\fhdoom-master\neo\tools\comafx\StdAfx.h   38

Error   C1083   Cannot open include file: 'afxwin.h': No such file or directory (compiling source file Q:\fhdoom\Work_folder\fhDOOM-master\neo\TypeInfo\TypeInfoGen.cpp)   TypeInfo   q:\fhdoom\work_folder\fhdoom-master\neo\tools\comafx\StdAfx.h   38

Error   C1083   Cannot open include file: 'afxwin.h': No such file or directory (compiling source file Q:\fhdoom\Work_folder\fhDOOM-master\neo\framework\CmdSystem.cpp)   TypeInfo   q:\fhdoom\work_folder\fhdoom-master\neo\tools\comafx\StdAfx.h   38

Error   C1083   Cannot open include file: 'afxwin.h': No such file or directory (compiling source file Q:\fhdoom\Work_folder\fhDOOM-master\neo\framework\FileSystem.cpp)   TypeInfo   q:\fhdoom\work_folder\fhdoom-master\neo\tools\comafx\StdAfx.h   38

Error   C1083   Cannot open include file: 'afxwin.h': No such file or directory   fhDOOM   q:\fhdoom\work_folder\fhdoom-master\neo\tools\comafx\StdAfx.h   38
Title: Re: fhDOOM (modernized idTech4)
Post by: motorsep on December 22, 2016, 02:54:43 PM
Powers from above signal you to stop fooling around and move on with DOOM 2016!  O:-)
Title: Re: fhDOOM (modernized idTech4)
Post by: argoon on December 22, 2016, 03:45:13 PM
Quote from: motorsep on December 22, 2016, 02:54:43 PM
Powers from above signal you to stop fooling around and move on with DOOM 2016!  O:-)

Motorsep i appreciate the input you gave me on my grass system but you should stop telling other people what they should do with their free time, if you have nothing better to say then is better to not say anything at all.
Title: Re: fhDOOM (modernized idTech4)
Post by: MrC on December 22, 2016, 04:05:50 PM
Is this an MFC related issue? I remember having similar problems when I used VS express, although maybe this isn't an issue anymore? Unless you're not using express, anyway just a thought. Wish I could be more help.
Title: Re: fhDOOM (modernized idTech4)
Post by: argoon on December 23, 2016, 11:12:00 AM
Yes it seams to be a MFC issue but i'm using VS2015 and by eXistence instructions i shouldn't need that?

I'm using the free community 2015 version it should be the full version not express, is for this reasons that i was trying to avoid messing with the source code.



edit: Solved it, seams MFC is not installed by default in vs2015 community you need to chose to install it at VS2015 install time, fortunately it asked me for a update and i was able to install MFC by updating the IDE.
Title: Re: fhDOOM (modernized idTech4)
Post by: MrC on December 23, 2016, 08:24:57 PM
Excellent, I had just compiled it myself with 2015 and was going to see what I might have had set differently. Glad to see you got it working, that's good information to know. Merry Christmas, Happy Holidays and all the rest to everyone. All the best.
Title: Re: fhDOOM (modernized idTech4)
Post by: argoon on December 24, 2016, 08:47:01 AM
Merry Christmas, Happy Holidays to everyone as well.  :)
Title: Re: fhDOOM (modernized idTech4)
Post by: motorsep on December 24, 2016, 09:56:12 PM
Happy Holidays and let's mod DOOM 2016 already!  O0
Title: Re: fhDOOM (modernized idTech4)
Post by: VGames on December 25, 2016, 08:47:07 AM
Merry Christmas everybody!
Title: Re: fhDOOM (modernized idTech4)
Post by: argoon on April 15, 2017, 09:29:59 PM
eXistence i don't know if you still are reading this thread (or forum) but i have a couple questions/requests for you about fhDOOM, would be graceful for any reply.

First a explanation, I'm using your engine for a (non comercial) project of mine and i would like to be able to make custom glsl shaders for it (or at lest convert existant ARB shaders for it) but i'm just a noob at it, not a good thing when you want to do stuff i know :P , the problem is that next to my lack of serious knowledge on glsl and ARB shader programming, i also don't know how to write them in accord to the necessities of your engine, there's no documentation on it, from my days of messing with it on a trial and error style (cursing like crazy) i found at lest how to use your GLSL shaders on a material, is similar to the old ARB shaders but not exactly the same, happy with my progress, i decided to try convert a existant doom 3 fresnel ARB shader to GLSL, nice for me to learn and it would be useful, so I went read the old ARB documentation on the old ARB shader language, just to comprehend what all the MUL and ADD and SUB meant, at the same time tried to decifer the GLSL code that you used on your converted shaders, i opened the old ARB heatHaze code and your GLSL version and my chin dropped, it was not what i was expecting, they were very different, I didn't comprehend almost anything, even so i didn't gave up, read a little more gained some wisdom on it and decided to try to convert the fresnel ARB shader, exactly how it was written on ARB but using GLSL C like language and because i know how to code (at beginner level), i just thought, that couldn't be that hard? And a abomination was born, it does not work i only see a big white square on screen and i'm pretty sure i'm just clueless and this is not how it is done, i would like if you:

1: convert the fresnel ARB shader into GLSL for me in the proper way, with code comments if possible, so i see the diferences and how it is done.

2: if that is not possible at lest tell me if i'm going in the right direction, what i need to change, if i need to research some topic or is better for me to try another hobby. :P

The ARB code


# Fresnel shader written by inolen 2005
# http://www.inolen.com

#################
# vertex shader #
#################

!!ARBvp1.0
OPTION ARB_position_invariant;

TEMP R1, R2, R3, R4;

SUB R1, program.env[5], vertex.position;
DP3 R2, R1, R1;
RSQ R2, R2.x;
MUL R1, R1, R2.x;

DP3 R2, R1, vertex.normal;

SUB R3, 1.0, R2;

MUL R4, R3, R3;

MUL R4, R4, R3;

MUL R4, R4, R3;

MUL R4, R4, R3;

SUB R3, 1.0, program.local[0];

MAD result.texcoord[2].x, R4, R3, program.local[0];

END

################
# pixel shader #
################

!!ARBfp1.0
OPTION ARB_precision_hint_fastest;

TEMP A, C;

MUL A, fragment.position, program.env[1];

TEX C, A, texture[0], 2D;

MOV result.color, C;

MOV result.color.a, fragment.texcoord[2].x;

END



My abomination of GLSL code           be gentle...

vertex shader


#include "global.inc"

layout(location = 0) in vec3 vertex_position;
layout(location = 1) in vec2 vertex_texcoord;
layout(location = 2) in vec3 vertex_normal;
layout(location = 3) in vec4 vertex_color;
layout(location = 4) in vec3 vertex_binormal;
layout(location = 5) in vec3 vertex_tangent;

out vs_output
{
  vec3 R1;
  vec3 R2;
  vec3 R3;
  vec3 R4;
  vec3 pos;
  vec2 texcoord;
} result;


void main(void)
{
gl_Position = rpProjectionMatrix * rpModelViewMatrix * vec4(vertex_position, 1.0);

  result.pos = rpLocalViewOrigin.xyz;
  result.R1 = SUB(result.pos, vertex_position);
  result.R2 = sqrt( dot(R1, R1).x );
  result.R1 = R1 * R2.x;
 
  result.R2 = dot(R1, vertex_normal);
  result.R3 = SUB( 1.0, R2 );
  result.R4 = R3 * R3;
  result.R4 = (R4 * R3 ) * 3;
  result.R3 = SUB( 1.0, vertex_position);

  result.texcoord.x = (R4 * R3 ) + vertex_position;
}

vec3 SUB(vec3 op1, vec3 op2)
{
vec3 _result;

_result.x = op1.x - op2.x;
_result.y = op1.y - op2.y;
_result.z = op1.z - op2.z;

return _result;
}


fragment shader


#include "global.inc"

layout(binding = 1) uniform sampler2D texture1;

in vs_output
{
vec4 color;
vec2 A;
vec2 texcoord;
} frag;

out vec4 result;

// texture 0 is the cube map
// texture 1 is the per-surface bump map
// texture 2 is the light falloff texture
// texture 3 is the light projection texture
// texture 4 is the per-surface diffuse map
// texture 5 is the per-surface specular map
// texture 6 is the specular lookup table

void main(void)

frag.texcoord = texture2D(texture1, result.texcoord.xy) * texture1.xy + texture1.zw );
frag.A = frag.texcoord * rpSpecularColor;

frag.color = frag.A;
frag.color.a = result.texcoord.x;
}


My GLSL code doesn't work because it doesn't compile :s (obviously)  the console  prints errors about "undeclared identifier" R1 R2 etc don't see how that could be true, i declared them exactly like you did on your shaders and - cannot convert from "float" to "default out high 3-component vector of vector3", thinking about it as i write this, perhaps is the naming of the variables the numbers could be causing problems... 
I also forgot to include a function declaration for the SUB function (that i think is not even necessary but i did it like that at first just because the ARB docs show that its what SUB cmd does if coded in C, i didn't made the others like MUL, etc, in the same way because was redundant, in my recent modifications to the code i don't use it anymore.   
Title: Re: fhDOOM (modernized idTech4)
Post by: eXistence on April 18, 2017, 12:25:15 PM
from time to time i take a look at the forum.

don't look at heathaze.fp to learn how to port ARB to GLSL, because heathaze.fp is not a straight port.
heathaze.fp was the very first shader i re-wrote and i experimented a lot with it. The current version achieves a very similar effect, but is implemented differently.

IIRC heathazewithmaskandvertex is much closer to the original ARB shader.

It's hard for me find any time for fhDOOM at all, so i probably won't look into the details of your fresnel shader any time soon.
A few things i noticed after glancing over your GLSL:
* R1 and others are indeed undefined, you probably meant result.R1
* output of vertex shader and input of fragment shader must be equal (look at vs_output)
* R1, R2, etc. should be temporary values ('R' for register), you only need them in your vertex shader (don't pass them to fragment shader)

the new shader system is pretty much undocumented. I could write something up, but it won't help you very much when you are totally new to writing shaders. Writing shaders is not that trivial, especially with an engine like idTech4. The whole shader thing is pretty much hacked on top of Doom3's fixed-function-style material system. The shader system is not that cleanly designed and integrated like in a more modern engine.
Title: Re: fhDOOM (modernized idTech4)
Post by: argoon on April 19, 2017, 02:33:56 PM
Quote from: eXistence on April 18, 2017, 12:25:15 PM

don't look at heathaze.fp to learn how to port ARB to GLSL, because heathaze.fp is not a straight port.
heathaze.fp was the very first shader i re-wrote and i experimented a lot with it. The current version achieves a very similar effect, but is implemented differently.

IIRC heathazewithmaskandvertex is much closer to the original ARB shader.


Hello eXistence thanks for taking the time to reply, i will study heathazewithmaskandvertex to see what i can learn.


Quote from: eXistence on April 18, 2017, 12:25:15 PM

It's hard for me find any time for fhDOOM at all, so i probably won't look into the details of your fresnel shader any time soon.


Sad news about not having time for fhDOOM imo is a very nice engine, sad knowing its development could stagnate but i comprehend, working on it doesn't put food on the table, thanks for the changes to idtech4 you made this far and good luck with whatever you decided to do.

Quote from: eXistence on April 18, 2017, 12:25:15 PM
A few things i noticed after glancing over your GLSL:
* R1 and others are indeed undefined, you probably meant result.R1
* output of vertex shader and input of fragment shader must be equal (look at vs_output)
* R1, R2, etc. should be temporary values ('R' for register), you only need them in your vertex shader (don't pass them to fragment shader)


1) Ok i see what you mean i should have used result.R1 = result.Rx instead of result.R1 = Rx, etc.  facepalm

2) About the in and out struct's, yes i realized they should be equal by seeing the other glsl shaders you made, i just don't know exactly why but on my latest code i made them equal.

3) What do you mean by temporary? I think of them as variables just like in doomScript or C++, a place in memory where i save some type of value, the only way that i can think of making them temporary is if i replace the value in it for another?

3a) Ok i think i know what you mean about only needing them on the vertex shader, lets see they are just used as temp variables inside the vertex shader to calculate the reflection índice we don't need them in the pixel shader (frag shader) we just need the final result from the vertex shader calculation, i'm right?


Quote from: eXistence on April 18, 2017, 12:25:15 PM

the new shader system is pretty much undocumented. I could write something up, but it won't help you very much when you are totally new to writing shaders. Writing shaders is not that trivial, especially with an engine like idTech4. The whole shader thing is pretty much hacked on top of Doom3's fixed-function-style material system. The shader system is not that cleanly designed and integrated like in a more modern engine.

Please do, if you have some time to write something about the shader system, even if i'm new to all of it, will always help, me and others.

Yes writing shaders is not trivial and from my foray into it, i think i will stay at converting existent shaders if possible, because the maths on it are pretty much over my head.

Even if is not cleanly design and integrated does it work as expected for the most part? 


BTW after some google searchs on shaders specially fresnel shaders i found this link (http://kylehalladay.com/blog/tutorial/2014/02/18/Fresnel-Shaders-From-The-Ground-Up.html) on there you find the next HLSL vertex shader and frag shader:

VS
vOUT vert(vIN v)
{
vOUT o;
o.pos = mul(UNITY_MATRIX_MVP, v.vertex);
o.uv = v.texcoord;

float3 posWorld = mul(_Object2World, v.vertex).xyz;
float3 normWorld = normalize(mul(float3x3(_Object2World), v.normal));

float3 I = normalize(posWorld - _WorldSpaceCameraPos.xyz);
o.R = _Bias + _Scale * pow(1.0 + dot(I, normWorld), _Power);

return o;
}


FS
float4 frag(vOUT i) :  COLOR

float4 col = tex2D(_MainTex, i.uv.xy * _MainTex_ST.xy + _MainTex_ST.zw);
return lerp(col,_Color, i.R);
}


I then tried to convert it to GLSL for fhDOOM

This was what i came up with, still doesn't compile but at lest i'm only getting a single the error now:

[b]VS[/b]
out vs_output
{
vec4 color;
vec2 texcoord;
} result;

void main(void)
{
  gl_Position = rpProjectionMatrix * rpModelViewMatrix * vec4(vertex_position, 1.0);

result.texcoord = vertex_texcoord;

vec4 _Bias = shaderParm0;
vec4 _Scale = shaderParm1;
vec4 _Power = shaderParm2;

vec4 posWorld = rpModelMatrix * vec4(vertex_position, 1.0);
vec4 normWorl = normalize(rpModelMatrix * vec4(vertex_normal, 1.0));
 
vec4 I = normalize(posWorld - rpLocalViewOrigin);
float dotR = dot(I, normWorl);
result.color = _Bias + _Scale * pow(1.0 + vec4(dotR, 1.0, 1.0), _Power);

}

[b]FS[/b]
in vs_output
{
vec4 color;
vec2 texcoord;
} frag;

out vec4 result;


void main(void)

frag.color = texture2D(texture1, result.texcoord);

result = mix(frag.color, result.color);
}

Quoteerror #174 - Not enough data provided for construction constructor

walking the path there, pretty sure is something basic that i'm just ignorant about.

Any input from you or anyone else would be awesome, cheers.
Title: Re: fhDOOM (modernized idTech4)
Post by: argoon on April 19, 2017, 04:39:57 PM
after doing what eXistance suggested and seeing how he converted heathazewithmaskandvertex this is what my fresnel shader now looks like (inspired again on the ARB version).

VS
out vs_output
{
vec4 color;
vec2 texcoord2;
} result;

void main(void)
{
  gl_Position = rpProjectionMatrix * rpModelViewMatrix * vec4(vertex_position, 1.0);


float rTWO,rTHREE,rFOUR;

result.color = vertex_color;

vec4 rONE = rpLocalViewOrigin - vec4(vertex_position, 1.0);

rTWO = dot(rONE, rONE);
rTWO = sqrt(rTWO);
rONE = rONE * rTWO;
rTWO = dot(rONE, vec4(vertex_normal, 1));
rTHREE = 1.0 - rTWO;
rFOUR = rTHREE * rTHREE;
rFOUR = (rFOUR * rTHREE ) * 3;
rTHREE = 1.0 - shaderParm0;

  result.texcoord2.x = (rFOUR * rTHREE ) + shaderParm0;
}


FS
in vs_output
{
vec4 color;
vec2 texcoord2;
} frag;

out vec4 result;

// texture 0 is the cube map
// texture 1 is the per-surface bump map
// texture 2 is the light falloff texture
// texture 3 is the light projection texture
// texture 4 is the per-surface diffuse map
// texture 5 is the per-surface specular map
// texture 6 is the specular lookup table

void main(void)

vec4 A;
vec4 C;

//calculate the screen texcoord in the 0.0 to 1.0 range
A = vec4(gl_FragCoord.x/rpCurrentRenderSize.z, gl_FragCoord.y/rpCurrentRenderSize.w, 0, 0);

C = texture2D(A,texture1);

frag.color = C;
frag.color.a = frag.texcoord2.x;
}



Still doesn't compile

I Get two type conversion errors something like "cannot convert from vec4 to high float" that i can't seem to know how to solve and because the error massages don't tell what line of the shader code gives the error is very hard to debugg. :(
Title: Re: fhDOOM (modernized idTech4)
Post by: bitterman on April 20, 2017, 09:30:40 AM
Try to exclude shaderParm0 from VS, then try to compile it.

And 'vec4(vertex_position, 1.0)' expression looks strange for me.
Title: Re: fhDOOM (modernized idTech4)
Post by: argoon on April 20, 2017, 10:13:34 AM
Quote from: bitterman on April 20, 2017, 09:30:40 AM
Try to exclude shaderParm0 from VS, then try to compile it.

And 'vec4(vertex_position, 1.0)' expression looks strange for me.


I will try but the original ARB uses that shaderParm0 but instead refers to it as program.local[0], on my new modification i found that it was a vec4 so i changed it to a float by using a single component of the vec4.

That  'vec4(vertex_position, 1.0)' expression is exactly how eXistence  wrote it on all its shaders when he wanted to convert a vec3 to a vec4.

Btw was able to make it compile now, the fragment shader also gave me no end of trouble, some times the ARB to GLSL conversion is very straight forward other times you need to really think it through.   
It works but I didn't tested if it is rendering exactly like the ARB version, need to test and see.

Here is my new version

VS

out vs_output
{
vec4 color;
vec2 texcoord2;
} result;

void main(void)
{
  gl_Position = rpProjectionMatrix * rpModelViewMatrix * vec4(vertex_position, 1.0);


float rTWO,rTHREE,rFOUR;

result.color = vertex_color;

vec4 rONE = rpLocalViewOrigin - vec4(vertex_position, 1.0);

rTWO = dot(rONE, rONE);
rTWO = sqrt(rTWO);
rONE = rONE * rTWO;
rTWO = dot(rONE, vec4(vertex_normal, 1.0));
rTHREE = 1.0 - rTWO;
rFOUR = rTHREE * rTHREE;
rFOUR = (rFOUR * rTHREE ) * 3;
rTHREE = 1.0 - shaderParm0.x;

  result.texcoord2.x = (rFOUR * rTHREE ) + shaderParm0.x;
}


FS

layout(binding = 1) uniform sampler2D texture1;


in vs_output
{
vec4 color;
vec2 texcoord2;
} frag;

out vec4 result;

// texture 0 is the cube map
// texture 1 is the per-surface bump map
// texture 2 is the light falloff texture
// texture 3 is the light projection texture
// texture 4 is the per-surface diffuse map
// texture 5 is the per-surface specular map
// texture 6 is the specular lookup table

void main(void)

vec4 A;
vec4 C;
float alpha;

//calculate the screen texcoord in the 0.0 to 1.0 range
A = vec4(gl_FragCoord.x/rpCurrentRenderSize.z, gl_FragCoord.y/rpCurrentRenderSize.w, 0, 0);

C = frag.color;
alpha = frag.color.a;
alpha = frag.texcoord2.x;
result = texture2D(texture1, A.xy);
}
Title: Re: fhDOOM (modernized idTech4)
Post by: argoon on April 21, 2017, 02:10:18 PM
Don't know if is my GLSL that is badly translated, or if is other reason but testing the ARB in the vanilla idtech4 material editor and the GLSL in the fhdoom material editor show different results in a very similar material.

See the attachment.

Title: Re: fhDOOM (modernized idTech4)
Post by: argoon on April 21, 2017, 03:45:15 PM
This is my latest fresnel conversion i'm almost sure it is the most faitfull to the original ARB version but still the rendering is different.

VS

#include "global.inc"

layout(location = 0) in vec3 vertex_position;
layout(location = 1) in vec2 vertex_texcoord;
layout(location = 2) in vec3 vertex_normal;
layout(location = 3) in vec4 vertex_color;
layout(location = 4) in vec3 vertex_binormal;
layout(location = 5) in vec3 vertex_tangent;


invariant out vs_output
{
vec4 color;
vec2 texcoord2;
} result;

void main(void)
{
  gl_Position = rpProjectionMatrix * rpModelViewMatrix * vec4(vertex_position, 1.0);


float rTWO,rTHREE,rFOUR;

result.color = vertex_color;
result.texcoord2 = vertex_texcoord;

vec4 rONE = rpLocalViewOrigin - vec4(vertex_position, 1.0);

rTWO = dot(rONE.xyz, rONE.xyz);
rTWO = ( 1.0 / sqrt(rTWO.x) );
rONE = rONE * rTWO.x;

rTWO = dot(rONE.xyz, vertex_normal);

rTHREE = 1.0 - rTWO;

rFOUR = ( rTHREE * rTHREE ) + ( (rFOUR * rTHREE ) * 3 ) ;
//rFOUR = (rFOUR * rTHREE ) * 3;

rTHREE = 1.0 - shaderParm0.x;

result.texcoord2.x = (rFOUR * rTHREE ) + shaderParm0.x;
}


FS

#include "global.inc"

layout(binding = 0) uniform sampler2D texture0;


in vs_output
{
vec4 color;
vec2 texcoord2;
} frag;

out vec4 result;

// texture 0 is the cube map
// texture 1 is the per-surface bump map
// texture 2 is the light falloff texture
// texture 3 is the light projection texture
// texture 4 is the per-surface diffuse map
// texture 5 is the per-surface specular map
// texture 6 is the specular lookup table

vec2 fixScreenTexCoord(vec2 st)
{
  float x = rpCurrentRenderSize.z / rpCurrentRenderSize.x;
  float y = rpCurrentRenderSize.w / rpCurrentRenderSize.y;
  return st * vec2(x, y); 
}

void main(void)

vec2 A;
vec4 C;
vec4 targetColor;
float targetColorAlpha;

targetColor = frag.color;
targetColorAlpha = frag.color.a;

//calculate the screen texcoord in the 0.0 to 1.0 range
A = gl_FragCoord.xy / rpCurrentRenderSize.zw;

C = texture2D(texture0, fixScreenTexCoord(A));
//C = texture2D(texture0, A);

targetColor = C;
targetColorAlpha = frag.texcoord2.x;

vec3 col = targetColor.rgb;

result = vec4(col,targetColorAlpha);
}



UPDATE 1 - More modifications to the shader, still doesn't render exactly like the ARB version. :(

- On the original ARB shader the var A is done with a MUL (multiplication), like so:

MUL A, fragment.position, program.env[1];

- On all converted shaders from eXistence i see that he uses instead:

A = gl_FragCoord.xy / rpCurrentRenderSize.zw;   
OR
vec4 screenTexCoord = vec4(gl_FragCoord.x/rpCurrentRenderSize.z, gl_FragCoord.y/rpCurrentRenderSize.w, 0, 0);

I assume fragment.position is gl_FragCoord and program.env[1] is rpCurrentRenderSize, i just don't know why he uses that divisions instead of a straight multiplication like in the ARB version, perhaps it has something to do with GLSL not being cleanly implemented in the engine like he said?
Title: Re: fhDOOM (modernized idTech4)
Post by: eXistence on April 23, 2017, 06:57:30 AM
send me (via PM) full examples (map, materials, shaders, textures, etc.) for ARB and GLSL version and i will take a closer look at.


Title: Re: fhDOOM (modernized idTech4)
Post by: argoon on April 23, 2017, 08:10:41 PM
Hello eXistence, thanks for taking time on your busy day to see what the problem is, will do what you asked, i'm sure is something obvious that i can't see, we have a say on my country "those that don't know are like those that don't see".

btw for anyone that want to also try their hands at ARB to GLSL conversion, i found some imo very useful links online, that next with studying eXistence GLSL shaders, helped me enough to make mine compile, even if the final look is not what i was expecting.

http://www.redway3d.com/downloads/public/documentation/bk_bm_custom_custom_gpu_arb.html

http://www.redway3d.com/downloads/public/documentation/arb_quickref.pdf

http://www.shaderific.com/glsl-functions/

Is done tell me if you have any trouble seeing the PM message.
Title: Re: fhDOOM (modernized idTech4)
Post by: eXistence on August 21, 2017, 05:17:31 PM
wow! over one year has passed since the previous fhDOOM release. RL and other projects kept me very busy, so things became a bit quiet around it. After several requests from different people, i released a new version a few days ago:

http://www.facinghell.com/fhdoom/fhDOOM-1.5.2-1414.zip

This release contains mostly bugfixes and internal code changes. There is other stuff in the pipeline that is more visible and more relevant to the game, but i don't want to delay this any longer.

HF!
Title: Re: fhDOOM (modernized idTech4)
Post by: motorsep on August 21, 2017, 07:48:04 PM
Quote from: eXistence on August 21, 2017, 05:17:31 PM
... After several requests from different people, i released a new version a few days ago:

Cool!! Any news about adding VR support ?
Title: Re: fhDOOM (modernized idTech4)
Post by: argoon on August 21, 2017, 08:45:14 PM
Thanks eXistence, happy that you found time and motivation to work on your engine! :)

Will try to merge with the version i have, i did some deep changes to it but they are only on the game side of the engine, hope all goes well, because your fixes do sound like they will come on handy.

Btw sorry about the shader stuff was never able to do the test map that you wanted, but no problem i also decided to not mess with shaders for the time being.


edit: Don't know if is a placebo but i played doom 3 with your new engine version and i most say it runs fantastically, soft shadows and all, smooth 60+ fps's on a AMD R9 270X at 1080p.
Title: Re: fhDOOM (modernized idTech4)
Post by: grml4d on August 22, 2017, 02:35:37 AM
your project look great ... did you changed the audio so it follows win7...10 multispeakers ? instead of eax
did you updated the libraries : jpg , curl & ogg ?
i made a post having all these files : http://idtechforums.fuzzylogicinc.com/index.php?topic=380.msg6095#msg6095

Title: Re: fhDOOM (modernized idTech4)
Post by: motorsep on August 22, 2017, 07:45:02 PM
Quote from: grml4d on August 22, 2017, 02:35:37 AM
did you updated the libraries : jpg ... ?

But why?!
Title: Re: fhDOOM (modernized idTech4)
Post by: eXistence on August 23, 2017, 01:09:08 AM
@motorsep:
nope. VR support would be nice to work on, but i am not planning to invest in a VR headset any time soon, sorry ;(

@grml4d:
Updating the sound backend  to get rid of the old EAX stuff is on my ToDo list.

Yes, i am well aware of the fact, that some of those libs are pretty old, but they still compile and work just fine (only some minor tweaks for VS2017 were necessary).
I don't consider them a security risk, they are totally irrelevant performance-wise and they are only used very
occasionally in the engine (jpeg only for loading roq videos, curl only for downloading assets, so nothing really important).
Currently there is no point in updating them.

The only exception to this might be curl, because the linux version is currently build without it. I will probably update curl and integrate it when i look into the networking part.
Title: Re: fhDOOM (modernized idTech4)
Post by: grml4d on August 23, 2017, 12:47:46 PM
the files were made 10 years ago ...so updating jpg , curl & ogg will only be a good idea..
i searched and then looked at the files...the libraries should be very easy to replace...same goes with zlib and bfg edition .
the sound system for me is as important as updating opengl to vulkan or even more... O0 O:-)
playing in stereo is not as great as 5.1 or 7.1 ...  :-\
Title: Re: fhDOOM (modernized idTech4)
Post by: argoon on August 23, 2017, 06:09:48 PM
Quote from: grml4d on August 23, 2017, 12:47:46 PM
the files were made 10 years ago ...so updating jpg , curl & ogg will only be a good idea..
i searched and then looked at the files...the libraries should be very easy to replace...same goes with zlib and bfg edition .
the sound system for me is as important as updating opengl to vulkan or even more... O0 O:-)
playing in stereo is not as great as 5.1 or 7.1 ...  :-\

You only think stereo is bad because HRTF is not used in most games, ;)  also Doom 3 and idtech4 is capable of 5.1 and 7.1 sound from the beginning.
Title: Re: fhDOOM (modernized idTech4)
Post by: grml4d on August 24, 2017, 02:33:22 PM
i know it ....i have an x-fi ...but my recent computer that has 2 radeon 480 and use one for audio....is not seen as able to deliver 7.1...
as dsound was deleted... may be finding info on windows audio is not that easy...
the good old time of speaker in the case and waveformatex .....

may be that will help :  https://msdn.microsoft.com/en-us/library/windows/desktop/dd370802(v=vs.85).aspx
Title: Re: fhDOOM (modernized idTech4)
Post by: grml4d on August 25, 2017, 03:16:29 PM
i started to play the new fhDoom that advises some HD packs  :"]...that i also downloaded ..
so i put the wulfen_texture_pack_2.0.pk4 High-Res_Pipes_inoffical_wulfen_2.0_update.pk4 in the base folder with www_wulfen_texture_pack_20_fix.pk4 from gamebanana.com ... without any change in config or parameters..
despite my two rx480...i was having low fps and the feeling i was walking like a pirate with a wood leg..., beside that some part of the floor were totally black...very disappointing ...
i renamed the exe to doom3 , removed textures pack files and had a better fps but still a game not so smooth..with parts only at 30 fps .. with doom bfg i have 60 fps all time , same with doom 1.3.1 ..

may be a config can help for the hd pack.., i think you should try to optimize the exe itself by using some intel tools ..
Title: Re: fhDOOM (modernized idTech4)
Post by: Snehk on January 25, 2018, 08:10:30 AM
I have troubles building solution for MSVC 2013 using CMake on Windows 10. I have everything required to build it (exact versions mentioned in building section on GitHub), yet it throws out an error: Unknown cmake command "add_force_include".
Title: Re: fhDOOM (modernized idTech4)
Post by: revelator on February 13, 2018, 04:14:35 AM
cmake might have deprecated it, also had problem with it but in my case it put linker flags in the resource compiler causing it to fail building, so i had to edit them by hand. Probably need a better solution.
Title: Re: fhDOOM (modernized idTech4)
Post by: originalxboxrulez on April 05, 2019, 10:11:59 AM
Don't forget to change the game's resolution (fhDOOM does not yet select your native resolution automatically).

^^^ How exactly do you set your resolution? i edited the config to set my res but the game just errors out when i try to launch the game am i missing something here?

core2 quad q8300
8gb ddr2
8600 gts 256 mb latest drivers
128 gb ssd
win7
Title: Re: fhDOOM (modernized idTech4)
Post by: The Happy Friar on April 06, 2019, 03:38:04 PM
if it's like stock D3,
r_customheight, r_customwidth, for the monitor height/width respectively, r_mode -1 for custom resolution, r_customaspect for the aspect ratio of your monitor.
Title: Re: fhDOOM (modernized idTech4)
Post by: originalxboxrulez on April 07, 2019, 12:26:35 PM
Quote from: The Happy Friar on April 06, 2019, 03:38:04 PM
if it's like stock D3,
r_customheight, r_customwidth, for the monitor height/width respectively, r_mode -1 for custom resolution, r_customaspect for the aspect ratio of your monitor.

Ya it set that in the config file and it just errors out starting the game ''Doom3 has stopped working'' lol and of course i cant enter that into the console because game wont start :P

Here's what it says

Problem signature:
  Problem Event Name:   BEX
  Application Name:   fhDOOM.exe
  Application Version:   1.0.0.1
  Application Timestamp:   5994adcf
  Fault Module Name:   StackHash_0a9e
  Fault Module Version:   0.0.0.0
  Fault Module Timestamp:   00000000
  Exception Offset:   00000000
  Exception Code:   c0000005
  Exception Data:   00000008
  OS Version:   6.1.7601.2.1.0.768.3
  Locale ID:   1033
  Additional Information 1:   0a9e
  Additional Information 2:   0a9e372d3b4ad19135b953a78882e789
  Additional Information 3:   0a9e
  Additional Information 4:   0a9e372d3b4ad19135b953a78882e789

Title: Re: fhDOOM (modernized idTech4)
Post by: The Happy Friar on April 07, 2019, 04:58:16 PM
delete the config file & put your custom res in the autoexec.cfg file (you may need to make one, same folder as the config file).
That will eliminate something conflicting in the config.
Title: Re: fhDOOM (modernized idTech4)
Post by: originalxboxrulez on April 08, 2019, 01:01:46 AM
Quote from: The Happy Friar on April 07, 2019, 04:58:16 PM
delete the config file & put your custom res in the autoexec.cfg file (you may need to make one, same folder as the config file).
That will eliminate something conflicting in the config.

Didnt work :(
Title: Re: fhDOOM (modernized idTech4)
Post by: revelator on September 13, 2019, 12:50:03 AM
BEX is a buffer overflow error, can be in the code itself, in a driver or even in the OS.
Most likely its a bug in the GFX driver, AMD has had a few of those, but report it upstream anyway.