Implementing a D3 BFG Avidemo workaround?

[STiFU]

My student assistant had been working on the D3 BFG source code for some time now to export absolute per-pixel depth values in meters along with stereo 3d screenshots. The plan was to generate stereo 3d sequences with groundtruth depthmaps for my research. So, today we discovered recordDemo is broken in D3 BFG, which is a real bummer to me right now, because I wanted to record demos and use avidemo to export stereo 3d sequences with depth information. As it seems, fixing recordDemo is not an easy task, if possible at all. Chosing D3 BFG for this has been a real disaster so far. So many things not working anymore, grrr. But I guess implementing stereo 3d support into TDM would've been more cumbersome.

 

So, what to do now? I was thinking something along the lines of a realtime continuous screenshot+depth export supported by a RAM-disc-drive or SSD to ensure fast write rates. However, my assistant is not that knowledgable about the D3 (BFG) sourcecode and neither am I. So I thought, I'd ask some question here.

1. What about engine time? When I write a screenshot, does engine time continue? In other words, if writing the screenshot would take half a second, would the animations in the next frame be half a second later? This would basically destroy our new plan... :-/ Avidemo ensured nicely that this doesn't happen, no frames of the 60-fps sequence are skipped.
2. How and where could we add our code to export the frames? I guess we would need some cvar also the control wether realtime export is active or not.

[STiFU]

So, maybe it was a bit of a rash decision to create this thread, because we already found out a few things. Since we took RBDoom-3-BFG we will alter RB_ShowDepth to handle exporting Stereo RGB + Depth, which answers question 2. And regarding question 1, there seems to be a command to freeze the engine in the takescreenshot function. Now we only have to hope, that Doom won't do any frameskipping.

[AluminumHaste]

Well that's a shame, seeing as recordDemo is broken in TDM also.

[AluminumHaste]

from my experience with the screenshot command, using a high jitter value like 128, takes about a second to generate the screenshot. Animations work as normal afterwards.

[nbohr1more]

I think there's a RBDoom 3 fork with stereo support already if I recall. Gotta weed through a whole mess of forks on Github to

find it though...

[STiFU]

Well that's a shame, seeing as recordDemo is broken in TDM also.

It is?? Did that come with GPL?

[STiFU]

I think there's a RBDoom 3 fork with stereo support already if I recall. Gotta weed through a whole mess of forks on Github to

find it though...

Yes it is. That's exactly the fork we use right now. The problem is not the stereo 3d. We got that sorted already along with exporting absolute depth for screenshots. But thanks anyway. We now only need to be able to export sequences somehow.

[AluminumHaste]

recordDemo has always been in Doom since the beginning, not sure what you mean.

[SteveL]

I don't know anything about the recorddemo feature. I think I know where you'd have to hack animation time if that turns out to be necessary. Hopefully fixed by screenshot code already as you say. The renderer is in a different state while taking screenshots with lots of optimizations turned off, and they can last several seconds in real time for a big cube map. Is it a sequence of images you plan to export?

[STiFU]

Yes, a sequence of stereo 3d images with acompanying perpixel depth information. It would've been soooo easy to just have that done through avidemo, but alas, all usefull features are broken in D3 BFG...

 

 

recordDemo has always been in Doom since the beginning, not sure what you mean.

You just said recordDemo was broken in TDM and that was news to me. And my question was, when that might have happened, because it definitely used to work when we were still a D3 mod. Remember that benchmark demo on RTTC?

[motorsep]

We fixed recording and playback of demos in Doom 3 BFG, but I can tell you it was broken to hell. There are still a few number of issues to be fixed

[STiFU]

Yeah, I saw you in that RBDoom bug tracker issue I posted above, but at that time you said you still had to find an appropriate solution or something like that. So what's your current status on that and where can I find your repository?

[motorsep]

Unfortunately you can't find my repository as I haven't released the engine yet. I am currently debating whether to go with UE4 and drop my BFG-based engine (then I'd release source pretty soon) or keep working with it (then source won't be released any time soon).

[nbohr1more]

I thought Daniel Gibson fixed the Demo feature in Dhewm3 for vanilla. If so, we could adopt those fixes. Too bad those fixes don't directly translate to BFG...

[AluminumHaste]

My apologies about the misunderstanding, recordDemo and demo have always been in Doom 3. It was sometime around 1.03 I think, playing demos stopped working and just shows a black window.

I think that benchmarking with demos still works, you just don't see anything on screen.

 

 

Useful commands:

Demo Commands


recordDemo [demoname] - Records a demo of your current gameplay with the name specified. The demo is placed in your \Doom 3\base\demos\ directory by default. This directory is created the first time you record a demo.


stopRecording - Stops recording the current demo.


PlayDemo [demoname] - Plays back a demo with the name specified.


compressDemo [huffman, demoname] - Compresses a demo file of the name given using the 'huffman' compression scheme (the only one currently available in Doom 3), creating a new, smaller version of it with the extension .demo.huff in the \demos\ directory.


com_preloadDemos [0,1] - Preloads all demos. Set to 0 will reduce memory usage, which is recommended.


com_compressDemos [0,1] - If set to 1 will compress demo files recorded, reducing their size. These files may take longer to load.


demoShot [demoname] - Creates a screenshot for the demo file specified.


avidemo [demoname] - Creates an AVI from an existing demo.


avigame - Creates an AVI from your current gameplay.


com_aviDemoHeight [pixels] - Determines the resolution height in pixels for AVI demos generated through the avidemo command. The greater the size, the larger the resulting file.


com_aviDemoWidth [pixels] - Determines the resolution width in pixels for AVI demos generated through the avidemo command. The greater the size, the larger the resulting file.


com_aviDemoSamples [samplerate] - Determines the sample rate for AVI demos generated through the avidemo command. The higher the rate, the larger the resulting file will be, but the smoother it will play.


roq [filename] - Encodes a roq file, but requires the name of, and path to, the roqParam file.


Benchmarking Commands


benchmark - Runs a benchmarking procedure which uses progressively less pixels for the current image (screen size shrinks) until a result is provided at the end in the console.


timeDemo [demoname] - Runs a timedemo on the demo name provided. If no demos exist, you can use the default demo1 built into Doom 3. See the Neat Stuff & Conclusion section for more details.


timeDemoQuit [demoname] - Runs a timedemo using the demo specified, and then exits the game completely when done.

[STiFU]

So, exporting depth in realtime is already partially working, although the fps drop to 30 when it is active. We hope to reduce the framerate drop when using faster storage (SSD or RAM). But we still have some bug and it's a weird one! Our depthimage keeps shrinking horizontally in the first couple of frames until the width is halved, while the actual depth values remain intact. Any ideas?

[SteveL]

Hmm does it then stabilise at the third size?

 

No real ideas, but a few random things that spring to mind for you to consider:

 

Are you capturing it in an idImage, and if so have you set allowDownsize to false?

Are you using a rendercrop? That's the one circumstance where I've seen this happen in my own experiments.

Are you capturing into a texture / image that's a power of two size and larger than your viewport?

How are you copying the depth buffer? glTexSubImage2D? glTexImage2D? glBlitBuffer? Option #2 can trigger automatic downsizing according to a comment in the engine although I've not experienced it.

[STiFU]

No it stabilises at half the framebuffer width.

 

Thanks for the hints. I will investigate that on monday.

[STiFU]

Thanks Steve, it was in fact the automatic downsizing due to framerate drops. We now quick and dirty call ResetResolution() each frame.