I'm working on a VR version - early alpha

[cabalistic]

Did you look at the vertexcache branch?

[nbohr1more]

Yes, I didn't see anything like:

 

glMapBufferRange(GL_ARRAY_BUFFER, block->offset, (GLsizeiptr) size, access))

 

in there nor any abstraction that I could identify?

 

For comparison:

 

https://github.com/raynorpat/Doom3/blob/master/neo/renderer/VertexCache.cpp

 

Again, I can't speak to whether your implementation is better\worse I just know that Pat Raynor took BFG's code and added glMapBufferRange to

it based on Mh's VBO discussion.

[cabalistic]

BFG introduced an abstraction over the buffers called BufferObject, which are used by the VertexCache. You can find the glMapBufferRange etc. calls there: https://github.com/fholger/thedarkmod/blob/vertexcache/renderer/BufferObject.cpp (see e.g. implementation of MapBuffer).

 

Pat Raynor's variant is only a relatively simple change that changed the existing temp allocations to a MapBuffer approach without changing the general structure of the VertexCache. I actually ported the whole BFG VertexCache concept.

 

Again, on its own that probably isn't really worth the effort, but I expect it to make porting additional stuff easier.

Edited September 3, 2017 by cabalistic

[nbohr1more]

Thanks. I was going nuts because git search wasn't finding the code. I think it excludes branches

 

Yes, this is a major step towards getting the code aligned with BFG so we can port GPU skinning

(which is where we expect the biggest yields).

[cabalistic]

Yeah, GPU skinning is high on my list now. I think that's one of the areas that should really help both frontend and backend.

[duzenko]

So, this weekend I went ahead and ported the BFG-style VertexCache in full. This means that, instead of two frame temporary buffers and lots of individual vbos, there are now two larger frame temporary buffers and a single static buffer. The static buffer is filled during level load with static interactions and static model data. Everything else is now allocated on the temporary buffers and thus only valid for a single frame.

 

This means that the frontend no longer needs to make GL calls, which also means that it no longer needs the shared context and does not have to sync its GL calls. On the other hand, it also means that it currently probably recreates some vertex caches a lot more often than previously, since they are only valid for a single frame.

How about the light interaction geometry?

Are vertexes duplicated or indexes only each frame?

[cabalistic]

Anything that isn't static is recreated, including vertex and index caches. Not static is anything that wasn't created at level load. I ported some stuff from BFG which statically initialises some of the interactions and some of the model data. (And I think that's the part that doesn't work quite right when loading a save game, so after save game loading the level appears basically unlit.) There might be potential to make more things static or even get rid of them entirely.

[nbohr1more]

Right, you probably need some sorta state change check akin to what is done on the game side:

 

Light.cpp

 
// don't present to the renderer if the entity hasn't changed
    if ( !( thinkFlags & TH_UPDATEVISUALS ) ) {
        return;
    }
 

[Eldrad]

So I get major flickering.

 

What can I do to remedy this?

[cabalistic]

What kind of flickering? Where?

[Oktokolo]

However, the potential promise of the change is that it should make porting additional BFG features a little easier

So we could get soft shadows and tesselation and parallax occlusion mapping that make our wall corners look like they are made from seperate hand-modelled bricks?

[stgatilov]

It is great to hear that VertexCache is ported from BFG.

When you checked performance, I hoped you tested some level with many guards visible

Perhaps the new version should be profiled to check again what is going on.

 

There is another problem related to your threading changes.

Linux version currently does not link with the following error:

build/release/core/framework/Session.o: In function `idSessionLocal::FrontendThreadFunction()':
/media/sf_TheDarkMod/tdm/framework/Session.cpp:2990: undefined reference to `GLimp_ActivateFrontendContext()'
collect2: error: ld returned 1 exit status

Apparently, someone must implement this function with glx calls.

 

[cabalistic]

So we could get soft shadows and tesselation and parallax occlusion mapping that make our wall corners look like they are made from seperate hand-modelled bricks?

I was thinking more along the lines of performance-related features, e.g. GPU skinning, simplified interaction handling, multi-threading the frontend, ...

Does vanilla BFG even have soft shadows? That would surprise me, seeing as it still uses stencil shadows. I think you might be thinking about the RBDOOM improvements, which feature (soft) shadow mapping. But that is another can of worms entirely

 

@stgatilov: I'll see what I can do.

[nbohr1more]

I was thinking more along the lines of performance-related features, e.g. GPU skinning, simplified interaction handling, multi-threading the frontend, ...

Does vanilla BFG even have soft shadows? That would surprise me, seeing as it still uses stencil shadows. I think you might be thinking about the RBDOOM improvements, which feature (soft) shadow mapping. But that is another can of worms entirely

 

@stgatilov: I'll see what I can do.

 

We have some work done towards soft shadows, see the 2.04 renderer branch in SVN and compare to vanilla 2.04 source.

[AluminumHaste]

I was thinking more along the lines of performance-related features, e.g. GPU skinning, simplified interaction handling, multi-threading the frontend, ...

Does vanilla BFG even have soft shadows? That would surprise me, seeing as it still uses stencil shadows. I think you might be thinking about the RBDOOM improvements, which feature (soft) shadow mapping. But that is another can of worms entirely

 

@stgatilov: I'll see what I can do.

 

Stevel did a ton of work getting soft shadows, here's what they look like:

 

[AluminumHaste]

Also here's a clip from Requiem with softshadows turned on:

 

[cabalistic]

Hm, and these are still based on stencil shadows? What's the performance like?

[duzenko]

Hm, and these are still based on stencil shadows? What's the performance like?

Only SteveL knows but since I think his approach is stencil texture in FBO it should be roughly the same

[nbohr1more]

Yes, the stencil shadows are selectively blurred in an FBO using a screen-space PCSS algorithm.

Peformance seems to be better than fhDoom's Shadow Map implementation and is WAY better than Sikkpin's

old Soft-Shadow mod. Of course, we'd probably be in even better shape if this were merged into SVN trunk...

 

Can't comment on RBDoom3BFG, I don't have BFG assets\game.

[Oktokolo]

That soft shadows add a lot to the atmosphere. If they are already in the code since 2.04 - how to enable them?

[AluminumHaste]

They were never implemented in the core mod as they are unfinished.

There's a special fork with these changes in them, but they only run on TDM 2.04.

[Oktokolo]

They were never implemented in the core mod as they are unfinished.

There's a special fork with these changes in them, but they only run on TDM 2.04.

The videos suggested a pretty usable state. There seems to be a glitch when submerged in water. But it still looked very playable. Sad that it silently died in a test branch long ago.

[cabalistic]

Interesting, I was under the impression that it is rather problematic to get soft shadows with stencil shadows. But I don't really know enough about stencil shadows

 

@stgatilov: I implemented the secondary context for Linux. However, it's segfaulting for me in the asm code in Sys_GetClockTicks. If I comment that out, main menu is working fine, but loading a mission fails.

[nbohr1more]

Interesting, I was under the impression that it is rather problematic to get soft shadows with stencil shadows. But I don't really know enough about stencil shadows

 

The stencil buffer allows for alpha variance but the "stencil test" is binary so this requires you to alter the buffer data after the fact or copy to an FBO (etc).

 

This Penumbra Wedge document has lots of interesting details:

 

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

[HMart]

Those soft shadow stencil shadows look very good indeed, seams like the same tech used in the idtech 4 based Wolfenstein 2009, but they still don't solve one of the fundamental problems with stencil shadows, alpha textures, petty SteveL seems to be M.I.A, hope all is well with him.

 

I know Eric Lengyel, from when i played with the old C4 engine demo, learn a tonne from it, C4 add a mixture of stencil shadows and shadow maps but now, his new engine, doesn't use stencil shadows anymore, is all ( imo very good) shadow maps, i hope that some day i'm able to do the same for my version of fhDoom engine and you guys has well for TDM engine. IMO stencil shadows are obsolete, even pure shadow maps will go some day, replaced by a mixture of shadow maps and raytrace shadows.