Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Nodes use FBOConfig to add their desired FBOs to FBM #2431
Initial but working PR for the issue: Nodes generate and publish the FBOs they need, unless available already. All current-default nodes in this PR have
How to test
Please check any weirdness on rendering in the PR. Sorry for not specifying any particular rendering operation since all nodes were modified.
Dear @tdgunes I have now reviewed all the new code.
I guess the general comment is: this PR doesn't go far enough.
Let's take a step back and let's talk in broader terms what we are trying to achieve here. First of all, what are the important characteristics of an FBO? Its dimensions and type are the most obvious that come to mind. It can then have a number of possible attachments on top of the default (but not always present) color buffer: normals buffer, light buffer, depth+stencil buffer.
There are also more conceptual but no less important characteristics: some buffers come in pairs, so that one can be used for reading while the other gets used for writing, ready to be swapped when necessary. Some attachments are shared, i.e.
Finally, some buffers are regenerated in specific circumstances (but not necessarily the same circumstances for all FBOs) and some buffers don't change for the whole life of the renderer.
Now, when we look at the classes dealing with the FBOs, what do we have? Currently we have an omniscient FBM knowing more or less everything about FBOs. Then we have highly constrained Nodes: they have to work within the limits of what the FBM can do for them.
This is not ideal.
Ideally, the FBM knows very little. Ideally the Nodes are the kings that tell the FBM what to do. This way when modules add new nodes the FBM works for them, not viceversa.
Now, how do we achieve this? One way could be to make the FBM extremely dumb: just a "bullettin board" where Nodes "publish" their FBOs so that other nodes can find them and reuse them. The problem with this vision is that the FBM actually does one very useful thing: it can act as a single observer of the RenderingConfig regenerating the FBOs as needed and informing the nodes when necessary. The alternative would be for each node to monitor the RenderingConfig and they'd all have to find a way to coordinate with each other, to avoid attempting to regenerate each FBO multiple times. Obviously this is not a solution. On the other hand, the FBM as it is has to go through hoops to handle the special cases (shadow map, static buffers) and can't handle anything different if a module's node needed it.
Let me then introduce the broad strokes of a solution.
Have a BaseFBM and a number of specialized FBMs: (currently) one for display-size-dependent FBOs, one for shadow map resolution-dependent FBOs and one for static FBOs. Nodes register their FBOs with the specialized FBMs, not the base one. Nodes could potentially also register their own specialized FBM if they need something different. Specialized FBMs will then be in charge of regenerating the FBOs when/if necessary and informing the subscribed BindFBO state changes so that they can obtain the new fboIDs. Note that in this scenario FBMs do not need to know the FBOs they will hold. As each FBO instance in a specialized FBM can be treated like all others, specialized FBMs are just a slightly smarter <String, FBO> map.
Some additional notes:
Hmmm... 3:22am, fatigue is starting to set in. Let me close this comment here then. I have concerns about the whole FBOConfig architecture and usage as to me they should be transient entities, used only to generate the FBO but not retained or further manipulated. But let's leave them as they are and please focus only on the feedback I gave you in this comment.
I hope to attend at the event tomorrow afternoon. I hope you'll attend to so that we can discuss things further.
180 comments (with this one). I wonder if that's a record for Terasology.
Anyway, there are a few comments that did not get acknowledged. @tdgunes, you might want to go through them just to make sure you did everything but I think we could be in merge-ready territory already.
Can you please fiddle with the video settings please?
Just to make sure everything works as expected.
@emanuele3d It took a while to go through all of the comments again (for the third time, hoping not missed a one). I tested on various configuration, also checked debug displays and changing video resolution in window mode. I think it can be now tagged as [Ready For Merge].