i think that the custom framegraph framework could be added as library without many code changes. And enum here and there, but i think without adding any logic or complicated code
While personally i agree with .glslibs to be more used to allow sharing code and not dupplicating code.
but i do not understand what you mean by
i think that the custom framegraph framework could be added as library without many code changes. And enum here and there, but i think without adding any logic or complicated code
I mean im always up to “better extensive solutions”, but im just too dumb to understand what we could achieve with “custom framegraph framework” possibility.
Just a comment from user perspective, do not mind me
I guess what @zzuegg means is to move j3md, frag, vert, glsl related stuff into a separate .jar package, like assets.jar, so it can be customized or modified for secondary development without needing to recompile based on the engine source code?
I believe he’s suggesting the Lighting.j3md, Lighting.frag, etc… get moved out of jme3-core into something like jme3-core-materials. This would make it easier to replace with custom ones.
I think in general, the engine would be well served by making it more configurable/swappable… whether through code or just reorganization.
Just like how it has always bugged me about all of the things hard-coded into Application (which is why I moved that to an interface and made it LegacyApplication).
JME gets close with the JmeSystem-related classes but it would be nice if there was some kind of pluggable composition pattern to allow replacing bits as needed (see recent conversations about different joystick libraries).
This is exactly what I was trying to say, the concept of moving shader and material related stuff into a separate jar file like an assert.jar.
However, one problem is, JME3 users would still need to unpack that jme3-core-materials.jar, copy and modify the .j3md, .frag files etc and then repackage into the .jar? Right?
No. They switch their gradle dependency from “jme3-core-materials” to “cool-custom-materials”. Done.
Edit: depending on whose perspective you are taking. The user of an alternative set of materials or the author of an alternative set of materials.
In your own project, you can already replace JME’s assets one by one because the application resources almost always take precedence of JMEs. I do this all the time, actually.
Are you suggesting to support framegraph as a lib? I would not recommend that, it is meant to better refactor the rendering workflow in future JME3 renderer system, and to manage extending more advanced graphic features in a better way, just like you would not want sceneGraph to be a lib. Because it belongs to the most fundamental part…
ou can take a look at framegraph systems similar to google filament’s, it is very important.
With this changes, and the changes i proposes on the pull request it would make the core support your implementation. So the engine itself gets more flexible.
At this stage the framegraph library would suffer from the slow release cycles of the engine.
The proposes changes are minimal and would already have been merged by now. allowing users use your library already.
I see basically only upsides of having it as library.
Nobody cares about code quality in a library, no in depth code reviews, fast shipping/update/upgrade/evolve times.
TBH you are doing yourself a favor starting a a lib. It then could be merged to core at any time once the api is stable
I have not found a article clearly stating how the resolution works if there are multiple resources with the same name, thats why i propose this changes.
I see basically only upsides of having it as library.
Nobody cares about code quality in a library, no in depth code reviews, fast shipping/update/upgrade/evolve times.
Well here i would disagree just in this case.
I agree it might be like “LegacyApplication” that you can just override.(example)
But it should work by default and be within JME codebase like “SimpleApplication”(example)
What you say its similar like saying that SimpleApplication should be library and just extend LegacyApplication.
This functionality here is very core imo.
New JME users should have this functionality in beginning, noone is looking for library at the start. They do not even know if some library exist until they need it.
So it could be “Elastic” the way you say, but still within JME codebase and setup as default one.
This way both “elastic” and provided-finctionality works together.
I understand it might be harder for you to update to new JME version since you most probably got some own code. So lets make it both: elastic extensive + ready-core-functionality(that you can replace ofc)
On this point I disagree - I see strong upsides to having a framegraph in the engine, and many downsides to moving this to an outside library.
First, to the point of fast merges and releases, of course those are usually desirable - but they also come at their own cost of having “something else” to pull in separately, lots of potential for the third party library to become desynchronized from core development, etc.
Second, framegraphs (and similar frameworks for asynchronous computation) are powerful tools used by a lot of modern engines. A couple months ago we began discussing proposals for a future “jME 4” and what that would look like, and one theme that was consistent was that this new engine should be architected to make good use of modern rendering APIs (such as Vulkan). Modern APIs are heavily slanted towards being able to asynchronously load up the GPU with work rather than synchronously step through state changes (which are a driver abstraction over the asynchronous nature of what’s really under the hood) and wait for them to finish. One key aspect of graphics performance is saturating the GPU and keeping it saturated - if the workload is heavy enough to bog down a saturated GPU, then any sync points that stall it become critical bottlenecks. Framegraphs are an intuitive way to express tasks and their dependencies that are then straightforward to map to rendering resources in either a synchronous (traditional OpenGL) or asynchronous manner (lots of parallel buffering/shader dispatch), and as I understand it they’re kind of an industry standard now. I also don’t view the framegraph as something that’s likely to be volatile - I think this will likely stabilize quite quickly and need few changes over time, negating most of the benefits of putting it in a third-party library.
Lastly, there’s a worthwhile balance to hit between in-core versus third-party libraries. For the vast majority of users, I expect that rendering infrastructure is not something they’ll really want to mess with as a third-party library - it’s a complex area with many subtleties, not many people know it well, and most would probably rather be focused on building games than optimizing a renderer. It’s one thing to keep, say, voxel terrain in separate libraries, but it’s another thing to be putting critical engine functionality in libraries instead of in-core. I view rendering infrastructure as critical engine functionality, and I view having framegraphs as a large and important step forward - especially in light of plans for future major versions.
I agree that we should be cautious about pulling new things into core, but I disagree that this is one of those that should be third-party.
I perfectly know what framegraphs are used for, and why they are required. I also see that this should be the FUTURE path to go for jme3.
I am not just not ready to merge code that is clearly a WIP since on every second post i hear that is going to be done in version 2.
With that in mind i searched the past days for a solution that would allow the code to be used TODAY as a library by simply adding a dependency and one line of code. If that is too much work i don’t know what to say.
So instead of beeing eager to hit the merge button i spend time reading the code and looking for a cleaner integration. Maybe you should too
I dont care if its in the jme code space or outside, but initially as a separate module and replaceable should be possible
My thoughts are consistent with yours. Personally, I don’t think it should be moved out. FG is relatively simple for now just because I didn’t submit other stuff in this 1.0 PR, so it’s kept clean enough.
Also from a engine design perspective, its position is at the same level as shader and material. However, if the JME community largely thinks it should not be done this way, then I agree with the community’s opinion.
Additionally, at first I planned to write a renderer similar to JME4. The first thing was not to write wrappers for OpenGL, Vulkan etc, but to find an open-source FrameGraph framework, only with flexible control, management and organization of rendering resources, can we extend a more powerful renderer.
Just to be clear: we end up in the same place… a much better jme4 (or whatever version)
We are only talking about differences in how we get there. And recognizing that today we don’t know 100% exactly what it will look like so flexibility is key.
During development (incubation) it’s a lot easier to swallow separate libraries because they are guaranteed not to break existing users and can generally develop much more rapidly without those heavy concerns. Things can iterate very quickly and a bunch of different things tried.
…then the final step is rolling it back into core and only then do we really have to worry about what happens to existing users. And if 90% of them are already using the new library then maybe it’s not a concern at all. Anyway, legacy users can continue to use the legacy modules.
I believe this will not affect the old modules. It is just my personal design approach: it can be turned off, and all subsequent logic is completely consistent with 3.6.1. This means it has no impact on the new version, so should it be put in a third party library?
I explain from the following points:
As I mentioned above, it is used for more flexible management of rendering resources, rendering workflows and rendering paths. Although I have also implemented rendering path switching without relying on FG (but I have not submitted them in this PR (but they exist in my github link（https://github.com/JohnLKkk/jme3.4-temp/tree/johnkkk/jme3-core/src/main/java/com/jme3/renderer/pipeline）), because I don’t think it’s worth organizing the rendering path with the old JME3 scheme, while also organizing a rendering path with FG at the same time)
In most cases, FG will not be used by external JME3 users, unless JME3 users need to customize their own Pipeline, and JME3 users can turn off FG to continue using the old JME3 rendering organization.
It is just for subsequent rendering features. If I move it to a third party library, then for the graphical features I will enhance JME3 in the future, I need to do two things: one is to implement new graphical features with JME3’s rendering organization workflow, and the other is to rewrite the organization and implement new graphical features with my own third party FG library. For each new graphical feature, I may have to maintain two solutions: one for the old JME3 rendering management organization, and one to rewrite the rendering management organization with FG, and then at some future time point, completely overwrite the old JME3 organization scheme with the FG scheme. This is very costly in development…
but I have not submitted them in this PR (but they exist in my github link（https://github.com/JohnLKkk/jme3.4-temp/tree/johnkkk/jme3-core/src/main/java/com/jme3/renderer/pipeline）)
In this link, there is a set of rendering path switching implemented using the old JME3 rendering organization, without using FG, while I also include the FG version in this link. However, as I said, I need to maintain both versions at the same time for every new feature… unless I see more people suggest to do so, it is really not worth it.
The reason I did not submit this part of the code in this PR is that I do not want to organize a rendering path for the old JM3 pipeline while also rewriting the organization with FG again. If someone wants me to maintain the code for both pipelines at the same time, although it is really not worth it, I would like to see more suggestions. Otherwise I may only write new features for the FG pipeline.
