Jump to content
The Dark Mod Forums
Sign in to follow this  
cabalistic

Testers and reviewers wanted: BFG-style vertex cache

Recommended Posts

Alright, found the issue with black water (and other effects) when fbo was disabled. I messed something up in the MSAA fix, had nothing to do with the BFG vertexcache.

 

I stumbled upon some more code paths that could potentially be triggered on the frontend, where they absolutely must not be triggered if multi-core is enabled. It relates to map changes. But I'm not sure yet if that code is actually in use (possibly in a campaign?) or if it's a remnant of the Doom3 multiplayer. I'll keep an eye on it; if someone notices weird crashes during level transitions or when saving/loading a game, kindly notify me. :)

  • Like 1

Share this post


Link to post
Share on other sites

This is crashing to desktop when trying to Load "Shadows of Northdale" Strangely no error or offer to debug.

Just as if it was never run to begin with


Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

For me it quits with a FatalError: "AllocStaticVertex failed, increase r_staticVertexMemory".

Try setting "r_staticVertexMemory 65536", that works for me.

 

The BFG style vertex cache has a fixed size and cannot grow dynamically if needed. I set the default to about 40 Mb since that was enough to load all the missions I tested previously and I didn't want to waste GPU memory. Apparently needs to be a bit higher :)

  • Like 1

Share this post


Link to post
Share on other sites

@cabalistic

Did they create an account for you on the bug tracker?

You might want to look at http://bugs.thedarkmod.com/view.php?id=4813. Regret my Intel does not support no-error contexts.

...

I am getting a feedback loop on water. This is the spawn area in Old Habits 1. Or do we have a different thread for the framebuffer changes?

Share this post


Link to post
Share on other sites

For me it quits with a FatalError: "AllocStaticVertex failed, increase r_staticVertexMemory".

Try setting "r_staticVertexMemory 65536", that works for me.

 

The BFG style vertex cache has a fixed size and cannot grow dynamically if needed. I set the default to about 40 Mb since that was enough to load all the missions I tested previously and I didn't want to waste GPU memory. Apparently needs to be a bit higher :)

 

Thanks.

 

I am now able to load the mission.

 

As of the latest SVN revision, there is some sort of strange flickering in the fog (particles?) in this mission?

 

On to my main report.

 

The water reflection is currently showing the splash screen unless I do the following

 

1) Set r_useFBO 0 (requires r_nvidiaOverride 0)

2) Restart TDM

3) Start the mission with r_useFBO 0

4) Water reflection looks correct

5) Set r_useFBO 1

6) Water reflection now looks correct while FBO is enabled

 

I can possibly think of some hacky way to toggle r_useFBO off until the "PlayerReady" routine is done

but I don't think that's the right way to go ;)


Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

Hmm...

 

Now "No Honor Among Thieves" (mission 2, anoott.map ) bombs out.

 

The r_staticVertixMemory value has been raised from 64mb to 256mb with no improvement...


Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

Does that happen on the transition between missions? Do you have a savegame or a console command for me? Don't feel like playing through the first mission to reproduce this :)

 

But it's possible that map transitions hit one of the remaining places where the frontend/backend split hasn't been completed and it's trying to load a map on the frontend thread, which is not correct. You could try disabling multi-core and see if that helps. If that is indeed the root cause, I have a vague idea what needs to be done.

 

@duzenko: So you don't see these artifacts on 2.06 with fbo enabled? Because for me, framebuffer is a little buggy, either way. I think there is a potential feedback issue with the depth map which might be used while still rendering to it. It might be that we won't be able to avoid some copies at certain places.

  • Like 1

Share this post


Link to post
Share on other sites

Does that happen on the transition between missions? Do you have a savegame or a console command for me? Don't feel like playing through the first mission to reproduce this :)

 

But it's possible that map transitions hit one of the remaining places where the frontend/backend split hasn't been completed and it's trying to load a map on the frontend thread, which is not correct. You could try disabling multi-core and see if that helps. If that is indeed the root cause, I have a vague idea what needs to be done.

 

@duzenko: So you don't see these artifacts on 2.06 with fbo enabled? Because for me, framebuffer is a little buggy, either way. I think there is a potential feedback issue with the depth map which might be used while still rendering to it. It might be that we won't be able to avoid some copies at certain places.

Replication:

 

1) Install No Honor Among Thieves

2) Open console

3) Increase staticVertexMemory

4) Invoke "map anoott"

5) Map begins to load then crash to desktop. No "grey screen of death", GUI message, or MSVC debug options offered.

 

I'll enable the log and gather more detail tonight.

  • Like 2

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

Ugh. Nothing really informative in this log:

 

 

 

 

[game\DarkModGlobals.cpp ( 374):INI (INIT) FR: 0] LogFile created at 2018.06.05 20:55:20

[game\DarkModGlobals.cpp ( 377):INI (INIT) FR: 0] Executable last cleaned and rebuilt on Jun 3 2018 21:40:23

[game\DarkModGlobals.cpp ( 380):INI (INIT) FR: 0] The Dark Mod 2.06/64, code revision 7432 (7432)

[game\DarkModGlobals.cpp ( 426):FRC (FORCE) FR: 0] LogBegin: 0

[game\DarkModGlobals.cpp ( 426):FRC (FORCE) FR: 0] LogEnd: 0

[game\DarkModGlobals.cpp ( 426):FRC (FORCE) FR: 0] LogInfo: 0

[game\DarkModGlobals.cpp ( 426):FRC (FORCE) FR: 0] LogDebug: 0

[game\DarkModGlobals.cpp ( 426):FRC (FORCE) FR: 0] LogWarning: 0

[game\DarkModGlobals.cpp ( 426):FRC (FORCE) FR: 0] LogError: 0

[game\DarkModGlobals.cpp ( 436):FRC (FORCE) FR: 0] LogClass_FRAME: 0

[game\DarkModGlobals.cpp ( 436):FRC (FORCE) FR: 0] LogClass_SYSTEM: 0

[game\DarkModGlobals.cpp ( 436):FRC (FORCE) FR: 0] LogClass_MISC: 0

[game\DarkModGlobals.cpp ( 436):FRC (FORCE) FR: 0] LogClass_FROBBING: 0

[game\DarkModGlobals.cpp ( 436):FRC (FORCE) FR: 0] LogClass_AI: 0

[game\DarkModGlobals.cpp ( 436):FRC (FORCE) FR: 0] LogClass_SOUND: 0

[game\DarkModGlobals.cpp ( 436):FRC (FORCE) FR: 0] LogClass_FUNCTION: 0

[game\DarkModGlobals.cpp ( 436):FRC (FORCE) FR: 0] LogClass_ENTITY: 0

[game\DarkModGlobals.cpp ( 436):FRC (FORCE) FR: 0] LogClass_INVENTORY: 0

[game\DarkModGlobals.cpp ( 436):FRC (FORCE) FR: 0] LogClass_LIGHT: 0

[game\DarkModGlobals.cpp ( 436):FRC (FORCE) FR: 0] LogClass_WEAPON: 0

[game\DarkModGlobals.cpp ( 436):FRC (FORCE) FR: 0] LogClass_MATH: 0

[game\DarkModGlobals.cpp ( 436):FRC (FORCE) FR: 0] LogClass_MOVEMENT: 0

[game\DarkModGlobals.cpp ( 436):FRC (FORCE) FR: 0] LogClass_STIM_RESPONSE: 0

[game\DarkModGlobals.cpp ( 436):FRC (FORCE) FR: 0] LogClass_OBJECTIVES: 0

[game\DarkModGlobals.cpp ( 436):FRC (FORCE) FR: 0] LogClass_DIFFICULTY: 0

[game\DarkModGlobals.cpp ( 436):FRC (FORCE) FR: 0] LogClass_CONVERSATION: 0

[game\DarkModGlobals.cpp ( 436):FRC (FORCE) FR: 0] LogClass_MAINMENU: 0

[game\DarkModGlobals.cpp ( 436):FRC (FORCE) FR: 0] LogClass_LOCKPICK: 0

[game\DarkModGlobals.cpp ( 436):FRC (FORCE) FR: 0] LogClass_AAS: 0

[game\DarkModGlobals.cpp ( 436):FRC (FORCE) FR: 0] LogClass_STATE: 0

 

 

 

 

Time to build a debug executable...

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

Debug seems to be mostly a bust.

 

I tried the "Retry" option on this prompt:

 

post-3763-0-14887400-1528250720_thumb.jpg

 

but it just crashed to desktop.

 

Nothing new in Darkmod.log.

 

I tried changing:

 

(logical operator)

 


assert( bufferObject == 0 );

to setting the value:

 


assert( bufferObject = 0 );

on a lark to see what would happen but the same issue persists...
  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

Hm. I'll look into the debug build and try to find the root cause of the assertion.

 

Btw, since I just spotted it in your steps to replicate: I'm not sure if vertex cache size can be set in the running game. You may need to put it in your autoexec, or at least do a vid restart.

  • Like 1

Share this post


Link to post
Share on other sites

Unfortunately, I simply cannot reproduce this. I increased the default static vertex cache memory to 64 Mb (which is actually also the max possible value right now). I also looked into the place where you hit that assertion. If you are triggering that assertion, then something bad is happening, because that variable is definitely initialized to 0 If you started the game fresh and executed the map load directly, I can see no way how this variable could be nonzero at that location unless your stack is getting corrupted. In which case - the root cause caught be anything, anywhere :-/

  • Like 1

Share this post


Link to post
Share on other sites

May I request that you bump the limit to 72mb so I can do some further testing (and make the cvar archived)?

Perhaps something is happening with OS and driver variance... :(

 

(I was able to figure out the bit mask but not the related bits like the wrap.)

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

Upping the limit is not straight-forward, but either way, it's not likely to be the issue. After all, the size of the static data is constant and depends only on the map. (Unless there's some shenanigans going on somewhere that I'm missing.)

 

I did manage to trip the assert during video restart, e.g. changing missions. I fixed that, although a full vid_restart during a mission isn't currently working because the static buffer gets recreated, but never refilled (I think). I'll have to think about it.

  • Like 1

Share this post


Link to post
Share on other sites

Thank you.

 

After this change and adding the value to autoexec.cfg I can now load No Honor Among Thieves mission 2 "A Night Out on the Town"

(anoott).

 

However: Crucible of Omens: Behind Closed Doors fails with:

 


AllocStaticVertex failed, increase r_staticVertexMemory

At the highest available cache 131071.

 

Other findings.

 

1) The game keeps kicking me out to r_useFBO 0 on restart.

2) If I enabled r_useFBO before starting anoott, I cannot see under water. I appear to have some sort of scratch render

3) If I load anoott then switch maps to forest I get a cache memory alloc failed at 64mb.

 

So it seems it's not clearing the previous map's cache before allocating more?

 

 

4) Occasional (rare) cases of AI flickering out or popping shadows

5) Enabling tdm_lg_interleave 3 (higher than 1) can produce shadow artifacts (same with tdm_lg_weak)

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

OK.

I bumped the limit in my working copy to 256 then set the Vertex memory to 192mb and Index memory to 128mb
and Behind Closed Doors finally loaded.

It seems that the engine is not picking up my autoexec changes so I'm gonna back down on those values
and see if we get something more sane.

Edit:

Build with 128mb vertex and 64mb Index works. Going lower.

Edit 2:

80mb vertex and 32mb Index is working. Going lower.

Edit 3: Final values needed to load "Crucible of Omens: Behind Closed Doors"

80mb vertex and 18mb index. !!!


(72mb vertex fails. 16mb index fails.)

I got sick of building so I tested CVAR_ARCHIVE on these and it works well.

Still not sure why autoexec.cfg wasn't working but this will do now.

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

Can you upload&link the exe?


Task is not so much to see what no one has yet seen but to think what nobody has yet thought about that which everybody see. - E.S.

Share this post


Link to post
Share on other sites

That's beginning to sound wasteful, given that most missions require far less. Perhaps I should create a temp buffer in RAM to build the static cache and then only copy the used parts to the GPU...

 

I'll look into the other issues.

  • Like 1

Share this post


Link to post
Share on other sites

That's beginning to sound wasteful, given that most missions require far less. Perhaps I should create a temp buffer in RAM to build the static cache and then only copy the used parts to the GPU...

 

I'll look into the other issues.

Hmm. The BFG technical document claims that the move to GPU skinning reduced the memory footprint too.

 

Also, I may be recollecting bogus info but... I was under the impression that BFG streams the level in and out dynamically

more like a conventional modern engine rather than doing the "big gulp" that Doom 3 classic does where it loads the entirety

of the level assets all at once.

 

Which is to say that you may be right to deviate from that design until\unless we also include those features...?

 

One thing that seems to be affected with cache changes is particle rendering. I wonder if we're using too much

data on them? Perhaps replacing the particle systems with geometry instancing or other modern particle techniques

would reduce the pressure there. The complication is that we use "lit" particles for some of our vegetation (at least it's not shadowed).


Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

Well, so far we've been dealing with the static part of the cache; GPU skinning and particles only concern the dynamic part, so those are not really my main concern here. Then again, since the dynamic part is triple-buffered, it might also be a good idea to make that part able to rescale itself when needed to not make it needlessly large from the start. Downside would be that for 1 or 2 frames, a few objects might be missing if the previous size of the cache was hit. I'll do some experiments.

 

Do I have to read your last paragraph that you encountered some issues with particles that you think are related to the cache? If so, please point me in their direction.

Share this post


Link to post
Share on other sites

Do I have to read your last paragraph that you encountered some issues with particles that you think are related to the cache? If so, please point me in their direction.

When I loaded NHAT forest without the cache bump, there were lots of flickering from the fog particles in the forest.

Now it's working as expected except maybe inside the manor where either particles or shadows are rendering some flickering

near the stairway. It sorta looks like the patches for the moonbeam\god-ray emitters there.

 

Northdale still has some flickering particle issues but seems to have less now that I've bumped the cache.


Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...