Debugging RB-D3-BFG (crashing on monster spawning)

[qModR]

Hi. When I try to spawn the 68th monster game crashes.
I've compiled the dbg build and made some tests. Here's the info I've got so far:

error screencap and a call stack from VS2013 Community Edition
https://drive.google.com/folderview?id=0B2vzAme0yU8DflZGMHc4Tlp2ZUpDajB5X0hyaDBjXy15T1NDQVJsWHUwUFdTdk85SmZjUUk&usp=sharing

It looks like the issue is with memory (de)allocation?

Video (first the Release build, then Debug)
https://www.youtube.com/watch?v=09HQxlsfcyk

Can anyone help me figure this out? Maybe someone can test this?

[trebor]

Nice I like detailed bug reports.

According to your backtrace: RBDoom3BFG_Debug.exe!idLib::Error(const char * fmt, ...) Line 213   C++

So you can start the test again with the arguments +set logfile 2 and paste the error message printed there in the newly created qconsole.log file.

[qModR]

I uploaded the log but I don't see any useful info there. It stops right on last spawn command.

What lines should I look at in the call stack? We need the last commands executed, right? What is the order of display -  top to bottom or the opposite?

I thought it was

Code Select Expand

RBDoom3BFG_Debug.exe!Mem_Free16(void * ptr) Line 80 C++ so I figured it has smth to do with mem (de)alloc's? Assertion failure from dbgHeap.c also pointed in that direction... But this is my first attempt at debugging ever... So I really barely understand what I'm doing here. I just try to apply basic logic...
So if I'm wrong somewhere (and I'm sure I am) please correct me.
What additional info can I provide?

[trebor]

Ah well the BFG renderer is designed to render primarily D3 content and that are the given contraints.

The VBO Cache is designed for multi threading and has a few static limits. You run out of memory for the GPU skeletons. You can try to increase VERTCACHE_JOINT_MEMORY_PER_FRAME in neo/renderer/VertexCache.h

[qModR]

OK, that worked out). 300 zombies - no crashing. And I've got a feeling this engine can handle a LOT more. Now I'm really excited!!! There's great power in this engine!
Thank you veeeeeeery much for your help, sir!!!

There are some other minor issues, but otherwise it looks very promising! Maaaaan, this is great...
https://www.youtube.com/watch?v=c3rzPR5bcKI

In the video you can see there are some performance issues when we deal with such AI numbers. So, if you don't mind, I've got a few more questions on that topic.

1. I'd like to know more about Game frames vs Renderer frames, relations between the two. What is done in G frame (physics, ai...)? Can you adjust how many G frames per second to simulate? How are G and R synced?.
2. AI calculations. Can they be adjusted as well? Like cycles per second or per G or R frame? Maybe AI can be made to think every other frame? How is AI calculation synced with the rest of the engine? Does AAS effect AI performance?
3. Is there a way to see detailed performance information about G frames at run-time? I mean like what makes up the number near G.
4. In performance counters (com_showFps) what is "rs"? Am I correct in thinking G to be Game frame time (ms), RF and RB - renderer Front-End and Back-End? What does GPU number mean and how is it related to actual [renderer FPS] and the [RF+G] number?

One interesting detail by the way: I noticed that even when I have as low fps as 10 my CPU utilization doesn't even reach 45%. It's mostly at 30-40%. But when I pause AI - fps spikes to 60 (my limit) and CPU usage is now like 40-60%, GPU usage is increased as well (more frames to render). This seems to be unbalanced.
(My CPU is i5 2500, GPU GTX660.)

I know I'm asking a lot of questions... If you don't have the time I ABSOLUTELY understand that. If this info is available somewhere on the net a link will do!
Anyway, I'll try to find as much answers on my own as I can.
And yes, I do understand, ofc, that the first place to look for that info is the SRC, but it requires skill and time.
Sorry for spitting out so much at a time, but it's just a lot of new info and a lot of questions, so I'm afraid I'll forget to ask something important...
And once more, thank you for your help!

[qModR]

Anyone can point me to the line where the monster is doing think()?

[motorsep]

Anyone can point me to the line where the monster is doing think()?

There used to be a forum called Doom3World. Sometimes when I'd ask something, I'd get a straight answer. Sometimes I would be told to go and look for Doom 3 does it

Check the classname of you monster. Then open a def file with that classname (or entityDef rather) and see if it inherits something via "inherit" spawnarg or if it has "spawnclass" spawnarg. Once you trickle down to "spawnclass", search C++ code (d3xp/) for that "spawnclass" (hint - it's idAI). That's where the core thinking is done.

[BielBdeLuna]

the monster "thinks" every gameframe, which in turns uses the scripting to do the aniamtions handling

there are four threads per monster, the general thread, the legs (that handles its animations ) the head, the torso

the AI is defined within idAI and idCharacter

all AI happens in c++ and then scripting decides to change state in a Finite State Machine format (FSM)

AAS it's for navigation only

on the g frame and r frame you have this study of the engine as a reference:

http://fabiensanglard.net/doom3_bfg/index.php

as well as this:

http://fabiensanglard.net/doom3_documentation/index.php

i hope it helps

[qModR]

Ok. It turned out to be a lot easier. Just set com_engineHz to 30 and it's fine. Sort of...

[qModR]

There are some shadow bugs with my model. Anyone knows what could be the reason?
It says in console:
WARNING: RB_DrawElementsWithCounters, vertexBuffer == NULL
Files
https://www.youtube.com/watch?v=PkSHX7znpYI

[motorsep]

Use vanilla shadow volumes and you'll have shadows planted properly.

But really, this engine isn't designed for stuff you want to make. I recommend using it more or less in line with what it was designed in mind (Doom 3-ish games in terms of space), or use UE4, since it is designed to handles a ton of enemies and vast open worlds (and it's also free with source code available).

[oneofthe8devilz]

One of the many reasons that made me stick with the 1.3.1 codebase and branch my custom code from there on...

[motorsep]

One of the many reasons that made me stick with the 1.3.1 codebase and branch my custom code from there on...

This particular issue is shadow mapping caveat. It should work fine with shadow volumes.

[oneofthe8devilz]

One of the many reasons that made me stick with the 1.3.1 codebase and branch my custom code from there on...

This particular issue is shadow mapping caveat. It should work fine with shadow volumes.

It is not a general caveat of shadow mapping... instead this is a case of a bad cascaded shadow mapping implementation in RB DOOM3BFG...

The showcased asset in the video above would work flawless in UDK, UE4, Unity and Cryengine without lightbleeding and bias problems if cascaded shadowmapping and according shadow map resolutions are used correctly...

I actually noticed rendering bugs for stencil shadows in D3 BFG compared to D3 1.3.1 which get especially worse when the camera closes in...

[BielBdeLuna]

it's not a competition, it would be great to have this soft shadow bug sorted out.