F3 Overlay Explanation

[Ravenwing]

This isn’t a support request per se, but thought it would be helpful to people diagnosing problems. I realized while I was trying out akortunov’s fade out feature for actors that I really don’t have more than the vaguest idea what most of the F3 overlay items even mean. Would it be possible to get a brief discription of what each item means, which hardware is the dominating force for that item, what the units are, and maybe just any other pointers on how to read the info?

If this has already been described somewhere feel free to link me but didn’t come up with anything from a quick forum search (not helped by the fact I can’t remember what the overlay is actually called). Maybe we can pin this and add the info to the docs as I think it’s a valuable tool for people to use.

[AnyOldName3]

The Draw bar could be CPU or GPU bound, but everything else is CPU-only. If you've pressed it again to get a list, it should be mostly reasonably easy to guess what each item means, but I can answer any specific questions. I can't remember what's listed off the top of my head except for the obvious things which you've probably already got a good idea about.

[akortunov]

Script, Mechanics and Physics are our bars, other ones are internal for OSG.
Script - we update scripts here, both global and local ones.
Mechanics - we update game mechanics here, including AI, magic effects and animations.
Physics - it is actually a world update, so it is a misnomer a bit. Here we update weather, projectiles state, camera and physics (both animated collision shapes and actors collisions).

Event - time which OSG spends to handle internal events.
Update - time which OSG spends to traverse scene via UpdateVisitor and execute update callbacks. Here we update controllers and initialize skeletons.
From what I can tell, UI update also affects this bar.
Cull - time which OSG spends to traverse scene via CullVisitor and execute cull callbacks. Here we update things which need to be done only for objects in the camera sight (e.g. skinning, terrain paging, light sources update).
Draw - time which OSG spends to tell GPU what to render and await for results. It is a separate thread in OpenMW, so in theory this value in profiler should be near frame duration.
GPU - it is a GPU time. A value should be near frame duration too.

[Ravenwing]

Thanks guys! I think based on my misunderstanding of what cull was for means I probably didn't actually have a good understanding of what happens in each item. Few more questions on these:

Event - time which OSG spends to handle internal events.

What constitutes an "event"? I'm guessing this is some kind of OSG jargon for something very specific.

Draw bar could be CPU or GPU bound

In what cases would it be CPU bound rather than GPU?

Cull - time which OSG spends to traverse scene via CullVisitor and execute cull callbacks. Here we update things which need to be done only for objects in the camera sight (e.g. skinning, terrain paging, light sources update).
Draw - time which OSG spends to tell GPU what to render and await for results. It is a separate thread in OpenMW, so in theory this value in profiler should be near frame duration.

How are these different? It sounds to me like both are going through the scene and deciding what it is that actually needs to be displayed.


Also, I think I remember now that the units for these are milliseconds? So that means for "near frame duration" essentially means inverse of FPS?

[akortunov]

How are these different? It sounds to me like both are going through the scene and deciding what it is that actually needs to be displayed.

As I understood, culling just decides which scene nodes to render and which do not, and allows to make custom calculations for nodes which are meant to be rendered. All calculations are computed in the main thread.
Draw is a separate thread which generates OpenGL calls for culled graph and sends them to GPU.
But I can be wrong.

Also, I think I remember now that the units for these are milliseconds? So that means for "near frame duration" essentially means inverse of FPS?

Yes, the frame duration is an inverse FPS.

[AnyOldName3]

As I understood, culling just decides which scene nodes to render and which do not, and allows to make custom calculations for nodes which are meant to be rendered. All calculations are computed in the main thread.
Draw is a separate thread which generates OpenGL calls for culled graph and sends them to GPU.
But I can be wrong.

This is the gist of things. The cull traversal traverses the scene according to the layout of the scene graph, collecting things into a different, flatter, data structure. The draw traversal then traverses the new data structure by sorted by OpenGL state, so that nodes with the same state get drawn together, minimising expensive GPU state switches. Translucent objects all need to be drawn in depth-sorted order right at the end, though, as they need to know what's behind them, which is slower.

In what cases would it be CPU bound rather than GPU?

On a modern GPU, some rendering commands can basically be queued up as quickly as the CPU can give them, and the GPU works on them as fast as it can. Other commands require the GPU to finish everything it's already doing before they can be started, so the draw thread would end up waiting for the GPU in this situation. Also, some OpenGL calls just take ages in general, which is sometimes the GPU's fault, and sometimes the CPU's fault.