[Enhancement] Graphics improvement

[johnyukon]

I see graphics are already being improved, we have better shadows now.

There are many mods created for DOOM 3 that may help in this task because they already have shaders and other stuff:

http://www.moddb.com/mods/sikkmod http://www.moddb.com/mods/perfected-doom-3-version-500 http://www.moddb.com/mods/parallax-mapping-mod-10 http://www.moddb.com/mods/g-t-x-d3 http://doom3.gamebanana.com/gamefiles/3756

There are probably many other mods around but I think that the most famous one is sikkmod. It comes with source code.

Also I don't know if this might help, but the Tesseract engine, based on cube 2 engine, implements some neat graphics effects, like real time global illumination:

http://tesseract.gg

I don't think graphics are the most important aspect of a game but it's needed to compete with proprietary engines and attract developers.

[nbohr1more]

I think you need PBR compatible assets... care to post an example material Tr3b?

Going back to the ambient. I've always wondered about the implications of adding SSAO as part of the ambient light interaction rather than as a post process since each ambient light is additive and you could get some interesting obscurance patterns by having brighter ambients overlap darker ones and modulate the amount of AO where brighter.

And while I'm back-tracking. I think it might be possible to take a high resolution normal map baked for a low-poly mesh programmatically color adjusted in the shader to keep from deforming when the underlying model is tessellated. You would simply map a relative color inversion per-poly. I wonder if anyone has tried that?

[RobertBeckebans]

If you want PBR in a total conversion then you need to replace

// HACK calculate roughness from D3 gloss maps // converting from linear to sRGB space give pretty results const half glossiness = clamp( pow( dot( LUMINANCE_VECTOR.rgb, specMap.rgb ) * 0.4, 1.0 / 2.2 ) * 1.0, 0.0, 0.98 );

const half roughness = 1.0 - glossiness;

with values from a texture that has PBR values for roughness. These values can be grabbed from glossmaps. However it would require to put those glossmaps into the alpha channel of the specularmap and change the .bimage format for that a specularmap might have an alpha channel or to change the renderer to look for "glossmap mytexture_g.png" files and pass them to the interaction shader along with the diffuse, normal and specularmap.

[BielBdeLuna]

if we include a new "glossmap" as a new material token which references either RGB (all channels the same image, which in my opinion would be quite a waste) or graysacle (just a single channel image) and passes it to the shader would it affect the *.bimage format?

[motorsep]

We implemented gloss in Storm Engine as standalone RGB image (same as specular).

[BielBdeLuna]

but that's not the point, it can be included as a token in the material, with more or less difficulty, but does it affect the *.bimage file?

[motorsep]

why do you care about .bimage ? It's just a container. Set you your gloss image properly and that's it.

[BielBdeLuna]

but that's what Robert said, that changing .Bimage was problematic if we included the gloss-map as an alpha. so still if we doesn't do it as a alpha channel but as an independent image. does it affect the format of .Bimage? that's the question

[RobertBeckebans]

It is no issue as independent texture. Even if you provide RGB channels as the source image then you pick a compression method for .bimage that provides only 2 channels or RGB compression like FMT_DXT1. It is better for the workflow to use a separate texture because you usually want to preview you models in tools like Marmoset Toolbag 2 or 3DO. Those prefer separate textures.

Or you go even further and use the compact model of UE4 and replace the specular texture with the following: R = metallic, G = roughness, B = Ambient Occlusion. And instead of using the specular .rgb for reflectance you can use the albedo * light RGB.

2014-09-29 22:00 GMT+02:00 Biel Bestué de Luna notifications@github.com:

but that's what Robert said, that changing .Bimage was problematic if we included the gloss-map as an alpha. so still if we doesn't do it as a alpha channel but as an independent image. does it affect the format of .Bimage? that's the question

— Reply to this email directly or view it on GitHub https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/145#issuecomment-57219656 .

[rudl]

"I don't think graphics are the most important aspect of a game but it's needed to compete with proprietary engines and attract developers."

I disagree, I'm very happy that doom3bfg runs mostly flawless on linux and other operationg systems and probably will another 100 years just like quake/II/II and doom^^ I'm not too much into graphics improvements and even prefer to turn off soft shadows.

[motorsep]

@rudl I agree with you on that one, however, you have to consider that these guys aren't making a game, but rather improving their software development skills in real-time rendering :) Plus, nowadays there are certain minimum expectations for graphics. So a few extra optional effects is a good thing to have.

Shadow mapping is a needed feature (although the current one requires to be optimized as it's not usable in the current state unless you have powerful PC). You could work around not having shadow mapping by using low poly shadow meshes, but that's just royal p.i.t.a. when it comes to animated characters :/

Even with all the features from all moderns engines, combined, BFG engine can run for 100 years, like Quake, because hardware is improving. So what's novelty and slow today, will be a norm and fast tomorrow.

[BielBdeLuna]

who is not making a game?

[nbohr1more]

Any interest in trying Penumbra Wedges just for shits and giggles:

http://www.terathon.com/gdc05_lengyel.pdf

?

It would be cool to compare.

[kortemik]

Yea I totally agree with nbohr1more, the semi-penumbral might even suit the game. http://fabiensanglard.net/shadowmappingPCF/ there are already examples in glsl here. http://fabiensanglard.net is an awesome resource regarding the engine otherwise too!

On Mon, Nov 3, 2014 at 1:47 AM, nbohr1more notifications@github.com wrote:

Any interest in trying Penumbra Wedges just for shits and giggles:

http://www.terathon.com/gdc05_lengyel.pdf

?

It would be cool to compare.

— Reply to this email directly or view it on GitHub https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/145#issuecomment-61429809 .

[johnyukon]

Just for you guys to know!

A new low level API called Vulkan from Khronos Group may replace OpenGL, and is being used in Source Engine 2. Vulkan has better performance and portability than OpenGL.

Check it out: https://www.khronos.org/vulkan https://en.wikipedia.org/wiki/Vulkan_%28API%29 https://www.youtube.com/watch?v=qKbtrVEhaw8

[BielBdeLuna]

Vulkan will be made ready to the public in October or something like this, Valve is using it already because they are a member from Khronos, only after the specification is out can we start using it.

I think Robert already said he is interested in Vulkan. and I hope the Vulkan driver in Mesa will be out as quick as they can, Intel already said they are working on it (as they are also in Khronos)

I think SPIR-V is already out isn't it? Would it be wise to start a GLSL exporter for SPIR-V if RbDoom3BFG already has a CG to GLSL exporter?

[Anthony-Gaudino]

We should wait for Vulkan and see how it works.

I have read on the Internet that recent versions of OpenGl add some features that greatly improve performance, getting closer to Vulkan's.

As Vulkan is a lower level API (runs closer to hardware) it will require more coding compared to OpenGL, also we already have access to a lot of OpenGl resources (code/documentation) around in the Internet, see bellow.

Please see https://github.com/tobspr/RenderPipeline/, its for Panda 3D (panda3d.org), and runs on OpenGl 4.x.

[BielBdeLuna]

There will be at least three versions of Vulkan, yo uwill be able to use Vulkan as a simple Graphics library like OpenGL, but if you want to go further down in the drivers code you can, so let's wait and see before judging it.