Questions on organization of draw loop

Basket · 2018-01-16T09:15:04

Hello everyone, just returning to gamedev after a long break. At the moment I am trying to understand at a " high level " how drawing is performed in games. To be honest its been a a struggle ... I am finding it hard to grasp the " big picture " and key , salient points as there are very many pieces that integrate and interact in many various ways. I understand the " low level " details to a certain extent : VBOs , render targets , shaders , uniforms etc. etc. The big uncertain area to me is how the " game " interfaces with the " drawing. " Basically how is drawing organized , the division of responsibilities , the coupling between " game logic " and the " logical update loop " in general with the " draw loop. " I have tried searching the forums and while there has been much discussion about these topics, I am personally having a hard time understanding the various approaches. From searching the forums I found a nice post from " haegarr " in a nice thread by " Ansharus. " Basically " haegarr " describes the " draw loop " as being more or less an extension of the " game update loop " consisting of the following steps : - Iterate over all meaningful objects in the scene of interest while apply a filter to select which of these objects to draw and in what manner ( e.g. compute LOD , compute current transformation matrices , update particle positions etc. ) - For each object selected to be drawn , insert a " draw task or job " into a queue ( a simplification ), where a " draw task or job " is effectively a complete description of the salient information required to draw this object ( e.g. VBO IDs , texture IDs , etc. ). - Sort each list of " draw tasks or jobs " to minimize draw state changes. - Process each newly sorted list of " draw tasks or jobs " ... basically (A) issue OpenGL commands to set all state changes as explicitly indicated in the " draw task or job " (B) activate VBO(s) (C) activate shader program (D) issue OpenGL draw command(s) to draw the geometry. Now the above is a simplification, certain things may be more complex. For example, there may be multiple lists of " draw tasks or jobs " ( e.g. one for " opaque " objects , one for a certain " draw pass " , etc. ). I actually understand this description of a " draw loop " .... but certain things are unclear to me. The biggest area I find difficult to understand is how does the " game " communicates with the " draw loop " as described above. From searching the forums, the " standard " approach seems to be to maintain a " scene manager " as a sort of database. And then have this database be a kind of central and shared " blackboard " data structure between the " game logic update loop " and the " draw loop. " Basically at the simplest level, the " game logic update loop " writes information to the " scene manager " and the " draw loop " reads this same information from the " scene manager. " Or at least that's what I think From certain descriptions the " scene manager " sounds very much like a unsorted list. In other descriptions the " scene manager " sounds like some complicated set of data structures ... a quad-tree , unsorted list of everything, sorted lists of specialized things etc. etc. I understand that a " scene manager " is very much defined by the specifics of the game. But I would be really grateful if someone could describe examples of " scene managers " just for illustration. For example, if you were to develop a city roaming game like " GTA5 " what kind of data structure(s) would you use for a " scene manager " , what types of objects might be maintained in it , what would add objects to and remove objects from it , how would game objects be added to and removed from it and at what times in the " update loop. " That sort of stuff Basically the " execution flow " from start of a scene to the shut down of a scene from the perspective of communication or interactions between the " game logic update loop " and the " draw loop " through the shared " scene manager. " But that's just the " scene " ... what about the objects themselves.... One particularly confusing thing to me is how do the game objects control in some way how they themselves are drawn. Lets say we have a " spaceship " with very many meshes , particle effects , and other great things. How does this spaceship get instantiated in the scene as a complete drawable object ? Where is its various drawing -related data stored ? What components are responsible for executing what drawing -related work ? How do these components executing drawing -related work communicate with each other ? From searching around the Internet, most game engines like Unity3D , have the " game logic " as it executes explicitly add instantiate and configure objects that are drawing -related and then change internal member variables of these drawing -related objects as desired over time. So in our spaceship example, the spaceship " game object " would instantiate and configure a " particle effect " object, insert it into the " scene manager " and then change its properties over time to change the drawable representation of this same spaceship " game object. " But again, where is this " drawing -related " data stored ... from searching the forums it appears that the " scene manager " only contains some of the data ... mostly the shared data that allows for communication between the " game logic update loop " and the " draw loop. " The more " drawing specific " data such as VBOs is maintained within the " drawing system. " So effectively there is a division of data between what is maintained in the " game logic " ( mostly " game logic centric " ) and that maintained in the " drawing system " ( mostly " drawing centric " ). That sounds pretty reasonable .... but what about the division of work ? The " game logic " should not be " updating " the positions of particles ... or should it ? From mulling things abit, I think the above description of the " draw loop " suggests that its a more " gradual " transition .... the " game logic " performs more " higher level " work to set internal state for the following " drawing -related " work , and then the " drawing -related " work performs successive " levels " or " layers " of more " mechanical " drawing -related work until we have " draw tasks or jobs " that can be sent to be drawn by a " minimal " OpenGL or whatever " interface " layer. So in our example , the spaceship " game object " would instantiate and configure a " particle effect " object, insert it into the " scene manager " and then change its properties over time to change the drawable representation of this same spaceship " game object " ... but the " drawing loop " would be responsible for " updating " particle positions , performing collision detection of particles , performing " culling " of particles and doing other more " low level " and " more mechanical " particle drawing -related work in some regular order one-by-one until we have " draw tasks or jobs. " Does this sound right ? Well that's it ... sorry for the basic questions and the length of this post. I am very much a newbie to game development. I would really appreciate it if someone could possibly explain to me how games do their drawing from the " game logic " down to the " insert draw tasks or jobs in draw queue " in a very newbie friendly terms I sort of understand the parts after the " insert draw tasks or jobs in draw queue " ... its the stuff that occurs before that is confusing for me

Graphics and GPU Programming Programming

Started by Basket January 13, 2018 07:51 AM

10 comments, last by Basket 6 years, 3 months ago

Basket

199

Author

January 16, 2018 09:15 AM

Thank-you so much haegarr for your help, I think I understand things enough to have a beginnings of a architecture

In my fire simulation example I was imagining something like a potential field or cellular automata implementation. As you say its a balance between defining and using more general or more purpose-specific " sub-systems. "

The right granularity depends on the domain and experience.

One really nice thing is that it does neatly compartmentalize things and should make things more easily understandable and allow for easier revision.

Questions on organization of draw loop

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Questions on organization of draw loop

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines