I'm working on a VR version - early alpha

[cabalistic]

Hm, the flickering skybox is a puzzler. It does not go away even if I disable parallelism, and the correlation with the lightgem parameters almost make me think this has nothing to do with my changes.

 

Well, except I can't reproduce it in vanilla 2.05, so it has to be related to something I did :-/

In any case, I think this is a very different issue than the previous one. Looks almost as if some lighting or shader parameters for the skybox get mixed up...

[BuckleBean]

 

For system crashes, turn 0's to 1's since I'm not sure what's causing your crash.

It might make TDM run slower, but this is only temporary. Once the game crashes, post the darkmod.log file here.

Sorry for the late reply.

 

No worries. I've been tied up. I'll try to see about getting to this tonight. However, I'd like to mention that I also tried to enable EAX via this tutorial: http://forums.thedarkmod.com/topic/18249-tutorial-how-to-setup-eax-for-tdm-on-any-soundcard/

 

I also saw a crash on startup. However, it boots up fine now, though EAX won't work. I get the message telling me that I don't have the required hardware. In both of these cases, user error is definitely possible. I'm certainly not immune to making mistakes. However, it's interesting that both are audio related. I know the VR headsets do some audio-related magic & I wonder if there's a conflict. I should try disabling VR to see if either HRTF or EAX are working.

[cabalistic]

@nbohr1more: I uploaded a potential fix for the flickering skybox here: https://github.com/fholger/thedarkmodvr/releases/tag/v0.1.3

The issue disappeared for me when I moved the lightgem rendering after the normal backend rendering. It previously sat at an awkward position after frame start, but before normal rendering, and may have overwritten a few default settings and the back buffer selection command. Honestly though, I don't fully understand why it affected the skybox, specifically. In any case, let me know if this fixes the issue for you, too, and if you can find any further problems

[nbohr1more]

Flicker is cured!

 

There are a few things like floating ragdolls at high FPS which have been cured in SVN via Blue_Pill's patches.

 

http://bugs.thedarkmod.com/view.php?id=4493

 

Also mantling in Swing can sometimes make you stuck inside geometry, same issue cured here:

 

http://bugs.thedarkmod.com/view.php?id=4435

 

And, of course, with high FPS your air supply in water depletes too fast (mentioned in the first bug).

 

Your decision to broach any of those issues in your 2.05 build verses just working in SVN nonwithstanding.

[cabalistic]

Ok, thanks. I'll get the combined fixes to SVN

 

Probably won't backport any fixes to 2.05; as I said, I'm going to try to get some further engine improvements into SVN. Doesn't really make sense to do that on 2.05 anymore.

[cabalistic]

Applied my fixes to SVN. However, I have a lot of visual artifacts on SVN right now, due to the GLSL shader changes.

[nbohr1more]

Try setting the "r_ignore2" cvar which is supposed to quarantine those GLSL changes.

I was gonna test that last night but ran out of time.

[cabalistic]

If I set r_ignore2 to 1, it crashes on start. Setting it to 0 (which is the default and should disable glsl) has the visual artifacts.

Edited August 17, 2017 by cabalistic

[nbohr1more]

@Duzenko!

 

...

[duzenko]

If I set r_ignore2 to 1, it crashes on start. Setting it to 0 (which is the default and should disable glsl) has the visual artifacts.

Umm... I set r_ignore2 after map loads. Any crash details (stack trace, ...)?

Fixed the missing qglProgramEnvParameter4fvARB for shadows in arb2 mode.

[cabalistic]

Thanks, that fixed the rendering artifacts.

 

With an x86 debug build, if I start the game, then set r_ignore2 1 in the menu and then load a mission, it will crash when level load completed with an access violation (null pointer) somewhere in the Nvidia GL driver. The last line of code from the Dark Mod at which the debugger points is in RB_RenderDrawSurfListWithFunction at line 262. Context is drawing the lightgem, the triFunc_ according to the debugger is RB_T_FillDepthBuffer. I'm afraid it skipped a few steps in the backtrace there, because that can't be the offending line. But it is repeatable.

 

If I set r_ignore2 to 1 directly in the autoexec.cfg, it fails right on startup somewhere when calling RenderSystem::EndFrame; again, the backtrace is incomplete, unfortunately.

If I set r_ignore2 to 1 after level load, it crashes immediately, somewhere.

 

Sorry that I can't really provide a good stack trace here. The null pointer exception in the GL driver might point to a null GL object being used, perhaps?

[duzenko]

Thanks, that fixed the rendering artifacts.

 

With an x86 debug build, if I start the game, then set r_ignore2 1 in the menu and then load a mission, it will crash when level load completed with an access violation (null pointer) somewhere in the Nvidia GL driver. The last line of code from the Dark Mod at which the debugger points is in RB_RenderDrawSurfListWithFunction at line 262. Context is drawing the lightgem, the triFunc_ according to the debugger is RB_T_FillDepthBuffer. I'm afraid it skipped a few steps in the backtrace there, because that can't be the offending line. But it is repeatable.

 

If I set r_ignore2 to 1 directly in the autoexec.cfg, it fails right on startup somewhere when calling RenderSystem::EndFrame; again, the backtrace is incomplete, unfortunately.

If I set r_ignore2 to 1 after level load, it crashes immediately, somewhere.

 

Sorry that I can't really provide a good stack trace here. The null pointer exception in the GL driver might point to a null GL object being used, perhaps?

Ain't I dumb!

I replaced qglVertexPointer with qglVertexAttribPointerARB in TDM myself just a few months ago, and I have been staring at the qglVertexPointer in the glsl code for hours and didn't see it!

 

It works now but bumpmaps are ignored for some reason.

[cabalistic]

Hah, I know the feeling all too well

[duzenko]

It works now but bumpmaps are ignored for some reason.

Actually they are not ignored, but the glsl shader somehow gives the normal map less weight in the output color.

Can anyone look at both shaders and have an opinion which one is more correct?

[cabalistic]

Which shader specifically?

 

Edit: The GLSL code path is still crashing for me, at the exact same place.

Edited August 18, 2017 by cabalistic

[peter_spy]

IMO current version od TDM engine is pretty sensitive when it comes to normalmaps. Other non-PBR engines like UnrealEngine 3 require stronger normals, and often you have to use the Multiply node in Material Editor to make them more visible.

[duzenko]

Which shader specifically?

interaction.fs vs interaction.vfp

The glsl shader wins in speed 35:33, probably because it does not do an additional cubemap texel fetch.

 

 

Edit: The GLSL code path is still crashing for me, at the exact same place.

Throw that nvidia garbage out and get yourself a real GPU like the one I have (Intel 5500)

[cabalistic]

Throw that nvidia garbage out and get yourself a real GPU like the one I have (Intel 5500)

Yeah... no As much as I do not like Nvidia, unfortunately I always found good reasons to still go with them (so far).

 

I had a quick look at the shader. One thing that surprised me is in line 33 in the normalize call, you are using wyz. Shouldn't that be xyz, or less confusingly, rgb?

[duzenko]

Yeah... no As much as I do not like Nvidia, unfortunately I always found good reasons to still go with them (so far).

 

I had a quick look at the shader. One thing that surprised me is in line 33 in the normalize call, you are using wyz. Shouldn't that be xyz, or less confusingly, rgb?

That is probably correct because the assembly shader does this

TEX	localNormal, fragment.texcoord[1], texture[1], 2D;
MOV     localNormal.x, localNormal.a;
MAD	localNormal, localNormal, scaleTwo, subOne;

No idea why they do that though.

As for the xyzw/rgba thing, AFAIK they are supposed to be the same thing.

 

None of the two shaders are mine actually. The assembly is from the previous TDM versions and the GLSL is from Pat Raynor.

[cabalistic]

They are the same thing, I just prefer to use the rgba accessors when accessing color values

 

Hm, that is strange. I looked at a normal map in TDM, and it is clearly using the rgb channels, no alpha. Maybe I looked at the wrong one, or the texture loading modifies the channels. Curious, though. Shame it doesn't run on my side, or I could play around a little.

[duzenko]

They are the same thing, I just prefer to use the rgba accessors when accessing color values

 

Hm, that is strange. I looked at a normal map in TDM, and it is clearly using the rgb channels, no alpha. Maybe I looked at the wrong one, or the texture loading modifies the channels. Curious, though. Shame it doesn't run on my side, or I could play around a little.

No, it's actually test_direct.vfp. Sorry

[cabalistic]

I meant a normal map texture, not the shader The textures have rgb channels, and r and g are definitely relevant. So unless the texture loading somehow transfers the r channel to alpha, then using the alpha channel in that calculation just doesn't make sense to me.

[duzenko]

 

Shame it doesn't run on my side, or I could play around a little.

Maybe try disabling vertex attributes in RB_GLSL_CreateDrawInteractions one by one?

[nbohr1more]

There's a small block of biases

{ x, y, z, a }

which we multiply our normalmaps by at the top of test_direct.vfp. These are what make our normals look deeper than the standard doom 3 versions. I'll post more details when I get some PC time.

 

Edit:

 

Here is a better illustration:

 

Biases:

 

 

 
# Scale the normal map scale up by a factor of 1.5.
PARAM    subOne        = { -1.4, -1.4, -1.0, -1.0 };
PARAM    scaleTwo    = {  2.8,  2.8,  2.0,  2.0 };
#PARAM    subOneN        = { -1.0, -1.0, -1.0, -1.0 };
#PARAM    scaleTwoN    = {  2.0,  2.0,  2.0,  2.0 };
PARAM    half        = {  0.5,  0.5,  0.5,  0.5 };
 

 

Normal map load:

 

 

 
# load the filtered normal map
TEX        localNormal, fragment.texcoord[1], texture[1], 2D;
MOV        localNormal.x, localNormal.a;
MAD        localNormal.xyz, localNormal, scaleTwo, subOne;
 

[rich_is_bored]

I haven't been following this discussion very closely so perhaps this isn't terribly useful but reading the posts about ARB and alpha reminded me of an issue I encountered when creating a color grading shader. I noticed that after a texture lookup, red color data was being stored in the alpha channel. You had to swizzle the channels around to correct it like this ...

# do lookup
TEX low, lut_coord, texture[1], 2D;
TEX high, lut_coord_high, texture[1], 2D;
MOV low.rgba, low.agbr;
MOV high.rgba, high.agbr;

I never really looked into why. I figured I was doing something wrong but it could be a bug in the engine.