FrameGraph API

Development Engine Development
1

Over the last several weeks, I’ve been working on improving @JhonKkk’s FrameGraph API. That project turned into a complete rewrite, which turned into another rewrite, so I guess this would be “JME FrameGraph, version 3.” Hopefully this one will make it into the core engine.

This API is based on the GDC presentation linked below, and on @JhonKkk’s work.

The goal is to provide a modular rendering architecture and a render resource manager to minimize resource creation and binding. While Johnkkk’s implementation worked, it did not provide a clean, reusable API. Therefore, I’ve reworked virtually all of the related Java code and API. I am finally ready to present the work I’ve done to the community for review so that hopefully this will get integrated to the core engine.

How the FrameGraph works

The FrameGraph, put simply, is an object that renders a ViewPort according to a list of passes. The FrameGraph can be thought as a node editor (like Blender’s shader editor), where each pass is a node, and passes, like nodes, can share resources between each other. The tricky part is managing the resources that pass between passes as efficiently as possible.

To handle resources, I’ve implemented a “lazy” resource manager, which attempts to minimize the number of existing resources by reusing resources where possible. It also includes a “reservation” protocol that allows passes to snag the exact resource they used last frame to minimize the number of texture binds that occur.

Rendering a ViewPort with a FrameGraph has 4 stages:

  1. Resource Declaration. All passes are expected to declare whatever resources they plan to use for rendering ahead of time, so that the resource manager can plan out which resources are allocated where and when.

  2. Pass Culling. Any passes which produce resources that are not then referenced by another pass are culled. This process is recursive, so once a pass is culled, whatever pass it was getting resources from might be culled as well.

  3. Execution. All unculled passes are expected to, during this step, acquire whatever resources necessary, do whatever is needed (like rendering), and release all declared or referenced resources.

  4. Reset. All resource pointers are destroyed (not the resources themselves), and passes do whatever cleanup is necessary.

All resources that are not used for the entire rendering process of all ViewPorts are deleted.

Here is the PR for this feature:

I would greatly appreciate any advice and testing. Thank you all for your support!

16 Likes
2

I am not a big fan of enums for things that are ment to be customizable.

enum RenderPath //in RenderManager.java

for example.

1 Like
3

Actually, that enum could probably be removed right now, as I’m not using it. It was left over from Johnkkk’s code.

1 Like
4

Nice. was not sure how much of johns code is still used from a quick lookover

1 Like
5

Most of his shader code is still in use, but his Java code is rapidly approaching zero at this point.

6

Thank you for taking the challenge for creating version 3 of the frame graph enhancements initiative.
So, if I understand correctly there are two parts for this feature, first is the " framegraph framework that supports 3 render paths" which is what Jonkk did for improving JME’s FrameGraph.
Second, is the API on top of that which the community asked for improving before merging the entire feature.
So if I’m reading this right, you modified both those parts to meet the community requirements (in the API part) and while doing so you also changed/improved large parts of Jhonkkk’s work.
This is really exciting! because now we have new ownership for this feature. did you try integrating it with v3.7? I’m curious to see whether or not we have major conflicts with existing code.

5 Likes
7

You’re welcome, glad to do it. :smiley:

I have not tried integrating with 3.7. I had assumed this feature would be integrated in the next engine release past 3.7, since we are now in feature freeze. Also, a feature as large as this will need a good deal of testing and bug fixing, so it will probably be a while longer before this is ready for release.

For merge conflicts, unless another PR has been messing around with rendering internals as well, I believe there will be very few, as the overwhelming majority of the changes are on new files.

3 Likes
8

Yes, of course it will need to be integrated in future release. I just was curious about conflicts. Actually the way we work here there is not much difference between updating from v3.7 or from master so whenever you update from master we will know about any conflicts.
I think Riccardo contributed some rendering code to v3.7 (a few thousands lines actually - quite big) so conflicts might occur.

1 Like