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
[RFR] Introduces API for module developers to add graphical tweaks to their mods #2449
Enables module developers to add their own nodes/render graph to rendering engine.
How to test
Try to enable the tutorial module and run the game. Confirm that colours are inverted.
Outstanding before merging
Which parts to expose to module developer is a good start. Because of the deadline, I might have wrongly put
Can confirm that the tutorial module works! :-)
I talked to @tdgunes some on Slack about potential architecture approaches to let modules affect rendering like this. I suggested a temporary approach that's less than perfect just so we can see it in action, and heck I'm even getting in on the action by writing my own shader based on this tutorial/API! Which is certainly a thing I had never imagined doing :D
The more ideal approach would probably hide some boilerplate code behind a new annotation like
I recommend we review and merge this with the understanding that the permanent approach along with some review of what modules should or shouldn't have access to later. We should submit a separate issue that could be done during or after GSOC, but before the next game release.
Any small stuff that could be improved in the PR immediately is fair stuff (including any
Edit: After understanding this a little better (actually wrote my own shader woo! Totally didn't just copy paste and edit numbers ...) I expect we are probably more looking at a
I can see how, due to the GSOC deadline, this is going to get into develop no matter my comments, but it's really the wrong approach and it will unnecessarily pollute the branch. We might want to consider this a learning experience, where during GSOC projects we'll want the last PR to be submitted some days before the deadline, so that we do not risk rushing it through for the benefit of the student and at the cost of the repository, leaving time for a proper wrap up period.
Right now @tdgunes you are clearing a 24 items list to re-insert a straight copy of it with an additional node. This also cascaded into having to open functionality to set the shadow map node, set the whole render graph and clear all FBOs.
How about removing all that and simply adding methods to append, prepend and/or insert a node into the node list? Wouldn't that make things simpler? If anything SampleGraphicsSystem.initialise()?
Really, it seems to me sleep deprivation and caffeine are are taking their toll!!!
Yeah I think we've all learned a lot this GSOC, many things to improve for the next one :-)
I'd love to see the single insert/remove/update/activate/deactivate of some sort. If my little goofy shader experiment should be possible to add or remove based on the player eating a mushroom I figure that should be done without that full 24 item redo
The good news is that this is entirely new functionality, so it doesn't really mess with anything existing. We could wait and merge it later or merge now then aim to improve before next release, or even mark it as an "incubating" feature exempted from SemVer ("Use with caution - may change" thing) - lots of big projects do that, like Gradle :-)
Actually, I bet we could even indicate that in the
For a node add function (with a specific spot in mind) would it work to pass an extra variable to indicate the name of the prior node to add the new node after? Throwing an error if said prior node is not found? Then as you mentioned on Slack document the available base nodes somewhere?
That's not perfect either, but this is a huge system we underestimated, I suspect we'll keep working on it for quite a while. On the plus side maybe we can eventually get to the promised land of only considering shaders matching a given OpenGL level somehow :D
Later on when it becomes a true graph maybe we can have a nice system that can figure it out itself akin to the world gen facets.
Maybe I need to revert my opinion. We probably should not expose internal classes and methods, which can easily break everything to modules, since this breaks the whole idea of the sandboxing approach.
I'd leave it locally for @tdgunes to create a proof of concept, but I'd rather not use it in the final version.
Yup this is just a proof of concept to show that it works. I think we should enhance
I'm fine merging this now or later, I don't think its merging actually factors into GSOC - this PR is listed on the project submission site either way so that's probably good enough - it does work! If we merge now we should clearly mark it as temporary code / API exposure that should not be relied on and either remove it before next game release or come up with a better "incubating API" flagging approach before then and apply it :)
Ultimately we may need a few different approaches to affecting rendering at differing levels of scope:
I think this PR should focus primarily on just allowing case 1. We can shrink it down to cover that better then start putting in post-GSOC issues to cover other cases, along with whatever else we want to do next. How does that sound? :-)
Edit: Maybe if we don't merge this right away we should use a new branch + PR for an alternative more narrow approach. That way this one can stick around for reference and for GSOC.
referenced this pull request
Aug 23, 2016
One way to implement the node registration in an extensible way would be to introduce a RegisterRenderEngineNodesEvent.
For each node there would be then a event handler that adds its node to a list of nodes the event has. Via the priority of the event handlers we can not just determine the order in which the events get registered, but we can also provide space for modules to hook in their own events. For this purpose we would not use the constants defined in EventPriority, but would introduce our own collection of event priorities:
If a module wants to insert a node after the world reflection node, it would do it like this:
The engine would register it's node the same way.
Hi @flo! Thank you for your contribution.
This PR is a bit misleading because it is based on a (temporarily) list-oriented rendering pipeline. That pipeline and all its nodes will eventually become a more explicit graph with nodes connected by edges. Different types of edges will likely have different meaning. For example one type of edge might simply describe which node should be processed first. Another might describe which camera a node uses.
I'd suggest we wait until we have that functionality implemented before we get into the nitty gritty details of how it could all work. There still is a fair amount of work to do.