News:

One Minute Game Review by The Happy Friar: https://ugetube.com/@OneMinteGameReviews
Also on Rumble: https://rumble.com/c/c-1115371

idTech 4 (aka Doom 3 tech) Discord Server! https://discord.gg/9wtCGHa

Main Menu

RBDOOM-3-BFG 1.1.0 preview

Started by trebor, December 30, 2015, 07:29:50 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

The Happy Friar

Try a "reloadengine" or exiting the game & loading it back up.  That's the only way I've found to reliably make sure video settings (besides the basics included in the stock game) read the changes.

Might not also hurt to rename the "doom 3.exe" to something else (I use "mickeymouse.exe").

Chromatose

Oh man RBD3BFG has come on hugely since I last tried.  Awesome stuff!
I've just been browsing the issue tracker on GitHub and I've noticed you have plans to support PBR-conformant materials, which is super exciting.  One question I did have is regarding the decision to eventually utilise displacement-mapping/tessellation.  I totally respect that the parallax-based method that Doom III modders have used up until now is a bit of a nightmare in terms of shader complexity, so please don't think I'm just having a moan about not implementing it; but the examples of tessellation-based displacement I've seen have absolutely butchered performance and looked really of weird and ugly.  Firing up Unigine Heaven and watching rock faces warp around as they adjusted complexity was genuinely a bit nauseating haha.

It could just be that I'm looking at bad examples, mind you.  I suppose I was wondering if it was something you'd toyed with yet, and if so, do you reckon it could work to the same extent that, for instance, modded DIII currently does parallax?

wintch

Quote from: The Happy Friar on January 03, 2016, 01:29:18 PM
Might not also hurt to rename the "doom 3.exe" to something else (I use "mickeymouse.exe").

Take into account that the binary naming is used by video card drivers in order to set specific optimizations and/or flags to get the game working.
Carmack mentioned once, that nvidia drivers were using quake1 filename to limit openGL extensions and make the game work, otherwise he would need to make a patch for it. I can't find the link now  :'(, but if something strange happens when renaming doom3.exe, you know what to do

argoon

#18
Quote from: Chromatose on January 05, 2016, 07:28:40 AM
Oh man RBD3BFG has come on hugely since I last tried.  Awesome stuff!
I've just been browsing the issue tracker on GitHub and I've noticed you have plans to support PBR-conformant materials, which is super exciting.  One question I did have is regarding the decision to eventually utilise displacement-mapping/tessellation.  I totally respect that the parallax-based method that Doom III modders have used up until now is a bit of a nightmare in terms of shader complexity, so please don't think I'm just having a moan about not implementing it; but the examples of tessellation-based displacement I've seen have absolutely butchered performance and looked really of weird and ugly.  Firing up Unigine Heaven and watching rock faces warp around as they adjusted complexity was genuinely a bit nauseating haha.

It could just be that I'm looking at bad examples, mind you.  I suppose I was wondering if it was something you'd toyed with yet, and if so, do you reckon it could work to the same extent that, for instance, modded DIII currently does parallax?

Tesselation is faster than POM (parallax occlusion mapping) or Horizon Mapping, and looks better especially at geometry corners, i know you add a bad experience with tesselation , like i did, and this i attribute to Nvidia sponsored games (almost all AAA games), they just use too much tessellation or extreme tessellation based effects like the Nvidia hair tech, why they do this, because their GPU's (high end GPU's) are better at it than AMD, but very well optimized tessellation (16x or 32x is sufficient, Nvidia uses 64x all the time) and applied only where it makes sense (on Crysis 2 they used 64x even on flat surfaces), makes no major visual diference to extreme tessellation and is faster then the same effect using POM, this is so for the simple reason that GPU's are good at rendering many millions of triangles, even smaller ones, but not so good at ray tracing that is something POM is based on, this is why tesselation is a major selling point in dx11+ and not POM or Horizon mapping.

p.s - Forgot to say Unigine Heaven is not a good example of optimal tessellation usage, is a benchmark so has tessellation tossed in at random just to stress PC's, there's surfaces there that really didn't needed tessellation and a normal map would suffice, for example the ropes and the rooftops and there's others.   

nbohr1more

Both Parallax and Tessellation can be done badly.

The problem with both effects is that people want to see "the effect" so it's often implemented in a very garish way
where the geometries are exaggerated from a subtle normal map.

Good Tessellation (or Parallax) is a subtle effect and will give a scene an almost intangible improvement and (in the case of Tessellation)
you'll also get a performance boost due to more efficient LOD management.

The reason that Carmack gave for not including Truform (DX8 Tessellation)?

"The Meshes would have silhouettes that didn't match the shadows."

And lo, most Doom 3 modders make "Shadow Meshes" which cause that mismatch issue anyway for the sake of performance (and I'll bet that vanilla Doom 3 has a few too).

Honestly, I believe he was planning on having Tessellation in Doom 3 because it was demoed along with early Radeon demos.
The blocky heads were perfect candidates to exaggerate the benefits.
He probably stopped working on it or yanked it after ATI employees leaked his E3 Demo.

The only thing I wonder about is whether it would be too expensive to adjust normal map projections in the shader to accommodate the new geometry without distortion.
Of course that's only a concern if you bother to render normal maps on top of tessellated geometry rather than just using tessellation in place of normal maps.

The Happy Friar

Quote from: wintch on January 05, 2016, 01:44:47 PM
Take into account that the binary naming is used by video card drivers in order to set specific optimizations and/or flags to get the game working.
Carmack mentioned once, that nvidia drivers were using quake1 filename to limit openGL extensions and make the game work, otherwise he would need to make a patch for it. I can't find the link now  :'( , but if something strange happens when renaming doom3.exe, you know what to do

That's why I've been doing it, ATI/AMD drivers have some hacks to "fix" issues with D3 that causes other issues with HDR, bloom, & what not.

Chromatose

Quote from: nbohr1more on January 05, 2016, 11:31:09 PM
The only thing I wonder about is whether it would be too expensive to adjust normal map projections in the shader to accommodate the new geometry without distortion.
Of course that's only a concern if you bother to render normal maps on top of tessellated geometry rather than just using tessellation in place of normal maps.

I was kind of under the impression by what Treb was talking about on the issue tracker was that you'd just have a displacement map defined in your material, which would feed either your normals or tessellation depending on setup, so it would be an either-or type of affair.

Quote from: nbohr1more on January 05, 2016, 11:31:09 PM
Good Tessellation (or Parallax) is a subtle effect and will give a scene an almost intangible improvement and (in the case of Tessellation)
you'll also get a performance boost due to more efficient LOD management.

Yeah, I think that's what I love so much about Doom III's S-POM implementation.  The effect was nigh intangible, and I couldn't tell what was making the new textures look so grounded in the rest of the world until I realised that they were all self-shadowing and occluding correctly.  It was a pretty incredible effect insofar as it didn't really 'stick out', but just made everything look way more convincing.

MrC

Awesome stuff! Really looking forward to the PBR stuff, I might not understand how it works but sure hope it'll help performance.


argoon

#23
Quote from: MrC on January 06, 2016, 04:52:50 PM
Awesome stuff! Really looking forward to the PBR stuff, I might not understand how it works but sure hope it'll help performance.

I don't think PBR will help with performance, all new graphical tech is always heavier than the past one but looks better, PBR (physical based rendering) is just a fancy name to say shaders/materials will now be more physically correct, like you make materials on 3D tools like Blender, Modo, Maya, etc, by changing physical properties, you will now be able to do the same on a PBR rendering engine.

In this example we have the Unity 3D PBR workflow more commonly known by metallic workflow, there's also the specular workflow that is very similar.



More examples

     

MrC

#24
Cool, thanks for the info argoon - very informative!

argoon

No problem :) i'm just as happy as you for knowing that eventually Doom 3 BFG will have the ability to render PBR materials, no pressure Treb take the time you want.

trebor

#26
r_forceAmbient adds quite a lot ambient light so I thought that it is a good starting point to bring SSAO into the game.

SSAO preview/comparison shots
http://imgur.com/a/eIdOA

MrC

Very cool, I for one really like the r_forceAmbient feature - been playing through Lost Mission again, trying different settings etc... (will report any bugs) and seeing so much more for the first time, looks like it works really well with SSAO. Reminds me of Quake4 multiplayer, where they used ambient light to brighten things up. Really awesome work Trebor. By the way, I know some people here are divided when it comes to editors and I know this is off topic but any plans down the road to re-add DoomEdit and/or the other tools?

motorsep

Quote from: trebor on January 08, 2016, 01:49:50 PM
SSAO preview/comparison shots
http://imgur.com/a/eIdOA

I wonder how Doom 3 would feel with all those effects turned on :)  Having spatialized audio would be an icing on the cake!

Is it just conventional SSAO technique or HBAO ?

motorsep

@trebor: Would it it be hard to add self-shadowing from normal maps? Would it have any significant impact on performance ?