Reorganisation to allow 3rd party supplied materials

[oxplay2]

About:

@zzuegg

I can only speak about the code in the PR and i think that one could be integrated as a library during the fast evolution time

@zzuegg as i remember you said it was your first PR and like you said for personal reasons. Im not sure what were this personal reasons, but please note most community demands such features inside core. They also have own personal reasons (they cant add deferred like you can yourself in your code)

There are more people with personal reasons to have this inside core(i guess even with John himself, so why break his motivation to improve JME by telling to do library?)
Because like said, not everyone is able add deferred himself or use illuminas that i seen no documentation at all.

@zzuegg i understand you got some reasons, but current way is how John want to make this, so just let him. - Library is not an option in this case (you suggested this and thats all, so just stop continuing library topic)

John is doing great work here and many people did PR his code already.

So in summary i suggest finish this library topic and continue PR code check topic and core-merging flow. (people want this in core same as author)

In fact, we all want JME to be very good and modern engine. - so we need this go into core.

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.

Nah, work your way, just one thats my opinion.

[zzuegg]

@oxplay2

personal reasons

My personal interest in rendering techniques.

[yaRnMcDonuts]

I think that there would be very little reason to ever fork and change a module such as “jme-materials” unless I am misunderstanding something

This is coming from someone who has 10 different forked versions of PBRLighting (AfflictedPbr.frag, AfflictedCreatures.frag, AfflictedGrass.frag, AfflictedPBRTerrain.frag, AdvancedAfflictedPBRTerrain.frag, etc)

I do still like the idea of moving the texture reads and everything before the lighting calculations from PBRLighting.frag into something like PBRLighting.glsllib so it is more modular and less work to maintain every fork. (this is something that is nearing the top of my to-do list actually so hopefully I’ll do this soon)

But I do not think I would ever be inclined to fork an engine module (like “JME-core-materials”) to make changes directly to PBRLighting.frag, that would be very unwise, since it is still extremely useful to have the stock PBR shader lying around in its un-modified form for comparison reasons. It is already easy enough to swap in my own custom shaders, I see no reason to add a whole new module called “jme-core-materials” just to do the same thing.

But as I said, maybe I’m still misunderstanding the benefit here… but isn’t it already easy enough to swap shaders and rendering techniques just by changing the .j3md file?

I’m no expert in the rendering-engine side of shaders, but it appears @JhonKkk managed to integrate his work in a way that doesn’t break the old materials, and only requires some extra init and using a different .j3md file (that is very similar to PbrLighting.j3md but points to a different .frag and technique). Isn’t this a sufficient situation, or is there still a reason that this would make it difficult to swap in your own custom rendering system?

[zzuegg]

It would allow external libraries to provide their own version of PBRLighting
That way every loader would use the new supplied one. You could actually have different PBRLighting versions for mobile or desktop, or in this case a PBRLighting that would write to your custom render targets.

It is not a fork, but a complete replacement.

The main point i tried to solve is that it could be done by anybody without modifications to the current shaders.

[yaRnMcDonuts]

So then we would essentially just be moving files out of jme-core and into jme-core-materials?

If that is the case then that should be a very minor change, and should probably be done after this new rendering system is integrated, that way we don’t lump more refactoring work in with the work of adding new features.

But until that happens, I don’t think there’s anything stopping someone from forking and changing jme-core to make the same changes that they would’ve made to jme-materials, right? (obviously this is less modular, and will require rebuilding all the other non-changed files in jme-core just for a few changes) so while it is an objectively good idea, I think the benefits are mostly related to convenience and shouldn’t be prioritized over the new rendering system.

[zzuegg]

@yaRnMcDonuts

So then we would essentially just be moving files out of jme-core and into jme-core-materials?

yes

@yaRnMcDonuts

I think the benefits are mostly related to convenience and shouldn’t be prioritized over the new rendering system.

The reason i looked into this is that the new rendering system could be added as a library.

[oxplay2]

@zzuegg

could be added as a library.

Already told to skip this topic, please… Just stop.

[yaRnMcDonuts]

@zzuegg

The reason i looked into this is that the new rendering system could be added as a library.

I personally think this new rendering system is ground-breaking enough that it needs to be in the core engine one way or another. I know this is a disputed topic, and I’d typically agree 95% of libs should be 3rd party (at least to start) but this is a big feature that we want new users to know about and use, and will inevitably want to merge into core eventually.

It does sound like you are right that there is a benefit to refactoring things this way, so that other renderers could be swapped in. But, as it stands, we don’t even have one good renderer in core.

So I think we should first integrate this new rendering engine, and then in the future wecould refactor things so that other renderers could be swapped with @JhonKkk 's implementation which will be present in core jme.

But as it stands, I strongly believe that JME needs a renderer thats on par with unreal engine included our core library. If we want to refactor things later so that the renderers can be swapped out easier, then I think that is a refactoring task best left for later.

[zzuegg]

I agree that the new system is way more flexible. I thing that it would evolve faster when done externally.

I also think that it should be added to the core. But once it is evolved to a point it does not require a new version every week.

Its not that libs are running 10% slower

[oxplay2]

@zzuegg

I thing that it would evolve faster when done externally.

But author know your suggestion and do not wish do this Your way.

So again… just stop.

[yaRnMcDonuts]

@zzuegg

I thing that it would evolve faster when done externally.

I would usually agree, but I disagree in this specific case.

This feature is so big and has garnered so much excitement that we do not need to worry about a slow release cycle slowing things down as much as usual.

If anything, I think this new feature will drive motivation to push more frequent jme releases in the near future, so we should capitlize on that if anything.

I also expect that there are a handful of jme users who would be excited to champion the next release to include these changes (I am one of them lol, although I hope that someone who already has experience managing a new release will do it, but I am so heavily invested in these changes that I will certainly step up and put my game on hold if no one else does, and will certainly be on hand to help test things at the very least)

So I think small features certainly are best in 3rd party libs, because no one has the time or motivation to push new releases to keep our master/alpha/beta branched up to date with such small features. But this is not a small feature, and there is a lot of motivation and excitement around it, so I don’t think we need to worry about theses changes being left on master for 2 years before someone decides to manage the next release.

And, as stated by others, I think the author of this new feature spent enough time writing it as is, so asking him to go back and turn it into a 3rd party library, only to inevitably re-integrate it into core, seems like a lot of wasted time potentially. So I think it should ultimately be his choice at this point.

[pspeed]

The issue is that on the current path it will be a really long time before the average user tries the new code. All zuegg and I are suggesting is a path that gets it into more peoples’ hands quicker. The end result is the same either way… it just happens much much sooner with zuegg’s approach.

With the current approach, JhonKkk also has to maintain a certain level of backwards compatibility during the whole process. A level of backwards compatibility that might not even be necessary in the end.

I think zuegg’s changes are a good idea regardless of whether jhonkk uses to make his job easier or not. We should do them, however that happens. I like the idea so much that if I weren’t strapped for time, and a few versions behind, I’d do it myself. I will help review a PR if it comes across my desk, so to speak.

I don’t want to discourage the work that jhonkk is doing. On the contrary, I’d even like to try it myself. Just trying to figure out ways to get to do that sooner.

In the end, it’s his choice, though.

Edit: perhaps we need some halfway point between “released in lock step with the engine” and “completely separate library”. Some kind of incubator area where we could release a “jme-next” library to maven central but on a more rapid schedule. Lives in the JME hierarchy, etc… imagine if the animation system had been done that way… it might have been complete before we integrated it.

[yaRnMcDonuts]

@pspeed

Edit: perhaps we need some halfway point between “released in lock step with the engine” and “completely separate library”. Some kind of incubator area where we could release a “jme-next” library to maven central but on a more rapid schedule

I’m far from an expert on managing testing for a big project like this, so I could be mistaking the purpose of things. But isn’t that sort of the purpose of having the master branch, and then also having automated snapshots for people that want to test the most up-to-date stuff easily?

I remember this topic about that recently:

Adding nightly builds to engine?

JME snapshots are now available on https://s01.oss.sonatype.org/content/repositories/snapshots/org/jmonkeyengine Thanks so much, @sailsman63 Edit: For using snapshot version add repositories { maven {url 'https://s01.oss.sonatype.org/content/repositories/snapshots/'} } and use 3.7.0-SNAPSHOT for jme version. For example: implementation "org.jmonkeyengine:jme3-core:3.7.0-SNAPSHOT"

Are these snapshots still being deployed? And if so, is that possibly a good solution to get people testing new things like this faster and easier?

As it stands, I don’t see how using a 3rd party library would be any faster than me just going to the fork that the author’s PR is based on right now, downloading the code, and building it. That’s just as easy as using a 3rd party library for me. The only difference is that I’d have to include the built jar instead of referencing a dependency link in my gradle script, but that’s a very minor inconvenience.

Also, as someone who struggled very much with my first 3rd party library I posted to jfrog for pbrTerrains (which eventually got merged to core and also got almost no use before that), I think it is fair for an author of a big PR to just say no to having to do all of that if the feature is as important as a new rendering system, and if it does slow things down, then I guess its better to get there slow than never.

[oxplay2]

Belive me Paul, this is discouraging. Author want to go certain way - and described exactly why.
Already zzuegg suggestion were provided “99” times, it is only discouraging to provide it “100-th” time now.

Author seen your comments, and wrote that anyway he need this to be in core due to future updates.

Also 4+ people wrote arguments that it need go into Core. Along with 7 likes under daniel post.

So why again write about same topic “100-th” time.

From all people i only seen you “kinda supporting” zzuegg library idea that is not working based on author update workflow.

Just look how many people want this to be in Core not lib.

Like John said:

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.

So now explain me how Library will provide Vulkan/etc backends?

This is like impossible.

Also which library do you know that were merged into JME in past 5 or 10 years or even more?

I belive none… New animations were PR, PBR were PR, both of them had issues on start and fixed later.

Basically everything were PR.

Minie is still library all the time since it started, tho i remember talks about putting it in core.
But Minie is exception here, since there are existing physics in JME code already, but there are no existing FG or deferred in core code…

Just look at another example zzuegg [illuminas] Library. Was this merged or anything? No because its just a library. And even here if i would like to use it i dont see any readme or docs or anything.
I belive only author and few people just use it in own forks who know how to use it.

i can give ton of examples.

Also like people already said, some things can stay as library, but not Rendering system that need to be part of Engine itself.

There are features that can be as lib, but not this one.

So if you continue zzuegg topic right now, its just like a stop for future Backends update and not only, because John need his PR(and future ones) to be in JME core, not libs. Thats why i repeat to leave this topic alone.

I belive most people want future multiple backend support and much more.

JohnKkk have a lot of support for his work and ideas.

Its just about that this PR is required in core for future “desired by people” features

btw. its late for me, so if i said something wrong way im sorry.

[pspeed]

@oxplay2

So if you continue zzuegg topic right now, its just like a stop for future Backends update and not only, because John need his PR(and future ones) to be in JME core, not libs. Thats why i repeat to leave this topic alone.

You are the only one pushing the meta-argument that the whole discussion is contentious.

If we cannot rationally discuss the pros and cons of an approach then we should disband the community.

As I’ve said, jonnkk can continue the way he’s going. I don’t want to stop him or derail his progress. I’m just trying to propose a way that his code might actually be reviewable and mergeable in a reasonable time given the resources available… while also improving the core of the engine as a whole.

…and that last part needs to be done regardless and need not wait for a future-thing.

If we don’t have a good way to incubate new technologies in a more direct way than “3rd party library” and in a less risky way than “merge to core” then every significant change requires a magnificent and tremendous effort on someone’s part. We should try to fix that.

Edit: and no “compile from source and tweak this thing” does not count as a “good way”… it’s just the only way we have right now. If we had infrastructure to get incubating libraries up in maven central it’s way easier for anyone to try something out… have real releases, etc… rather than grabbing some random build which is broken because the author is still working on stuff. PRs are not the same as published releases.

[pspeed]

@zzuegg

@pspeed

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.

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.

Yes, you are 100% correct… I take a big risk relying on this behavior. And the failures will look very strange.

[yan]

From my personal perspective, the new rendering system and FrameGraph are not so much a minor feature as they are a REVOLUTION.

Could we create a branch called 4.0.x and start adding FrameGraph features from there?

In the future, we can maintain two branches, 3.6.x and 4.0.x, just like spring-boot 2.7.x and 3.0.x

[danielp]

@yan

In the future, we can maintain two branches, 3.6.x and 4.0.x, just like spring-boot 2.7.x and 3.0.x

This is something I’ve been pondering over for a while now, and I’m leaning towards forking for jME 4. I expect that jME 4 is likely to have some pretty major architectural changes, so I think it’s likely to widely diverge from the existing codebase. At some point having two wildly divergent branches in the same repo seems counterproductive. I’m not hard set in that opinion, and of course it will be some time before we know just how extensive major changes are likely to be.

This is rather off-topic for this thread though, so if we wish to discuss it further we should take the conversation to a different thread (possibly this one).

[JhonKkk]

I’m sorry I came late, maybe I didn’t fully understand, but please let me know so we can analyze the two main entangled problems now:

1. Some people are worried that merging imperfect code into the core poses risks, which is reasonable.
2. Submitting features to PRs will delay the rapid use of new features, as one has to wait for a new jme release.

Let me re-explain my thinking and solutions to the related issues:

1. The FG feature is designed as a module “for the existing core”, it’s not that I can’t move it out to a third party library, but some features are weird if moved out to third party libraries (I made a standalone MobilePBR codebase 2 years ago, not put in the core, but as a standalone library, because that kind of code can be standalone). And “assuming” I only write rendering paths, global illumination systems, VRS, FSR, TAA and other modules for the FG system, then these should also be moved out to third party libraries, because they rely on the FG system. Then new users who want to experience new features will encounter the situation where jme3-core must rely on jme3-fg.jar to run, which is very unreasonable…
   The solution is that I implement these features using the old JME3 pipeline without the FG system, but then it becomes that I have to maintain two versions: the old jme3 pipeline version and the FG version.
   My motivation is: “To enhance and refactor the existing jme3 core architecture”.
   If I put these things in third party libraries, for JME3 users, future jme3.7, jme3.8… will not have these “features”, but jhonkkk-fg.jar, jhonkkk-gi.jar, jhonkkk-renderpath.jar these third party libraries provide these features, which is contrary to my “motivation” (my motivation is to enhance and gradually refactor the jme3 core architecture, not: make a jhonkkk third party library)
2. If I make it into an independent jhonkkk.jar library and contain many new features, the likely end result is a second JMB (this is why I later chose to study the SDK code instead of continuing to use JMB, because JMB is unlikely to become the official editor to a large extent),
3. As an incubation approach for new technologies, the approach I chose is (what I call Plan A): Embed parts of the new architecture code in each jme3.x version, then gradually transition from jme3.7 to jme4.+, and gradually replace the architecture.
   This approach is consistent with EpicGames’ engine development approach. I have experienced UE3->UE4->UE5: They embedded parts of the RDG code (i.e. FG system) between UE4.1->UE4.22, then completed 90% of the RDG system development in UE4.22+ versions, but during this period, UE4 users could use both RDG and old pipelines, then UE4.25 started to embed GPUScene code in advance, then developed 30% in UE4.26, 50% in UE4.27, during which users could get benefits from GPUScene, and finally completed 80% of GPUScene functionality in UE5.0, which is the Nanite system in UE5.
   Why not move it out as an independent library? It’s not 100% impossible, but the cost is higher, because this is used to refactor the core components of the engine.

Back to this problem “1. Some people are worried that merging imperfect code into the core poses risks, which is reasonable.”:
So I provide the approach of using switches - as long as execute enableFramegraph(false) or similar code, jme3.7 will be exactly the same as jme3.6, containing no new features. Even if I have to write a second RenderManager2.java, this RenderManager2.java should also be located in jme3-core.jar, not jhonkkk.jar, so users can choose not to use it, and there will be no conflicts at all. (Aside: I actually don’t want to rewrite a new RenderManager2.java, but refactor gradually instead)
Back to this problem “2. Submitting features to PRs will delay the rapid use of new features, as one has to wait for a new jme release”:
Can I submit PRs to the Master branch while allowing others to clone my repo and use cutting-edge features directly at the same time? Can this solve the demand of some people who want to use new features quickly before the PRs are merged? Or can I build something like a jme3-core-plus.jar, upload it to some maven repo for others to use?
I think these two things can progress at the same time without conflict, because after submitting PRs and merging into master, users can choose to close “unstable” new architectures by enableFramegraph(false), enableRenderPath(false) etc, but they can still immediately use “New Architecture 1.0” and “New Feature 1.0”; at the same time before PRs are merged into Master, users can clone my repo or download jme3-core-plus.jar or similar that I submit to maven repos for use.

If we cannot allow “Plan A” (i.e. the approach of embedding parts of the architecture code in advance, then slowly iterating from jme3.7->jme3.8->jme3.9->jme4.0), can we create a standalone jme4.0 branch where I develop these new architectures and features completely on this jme4.0 version? Meaning jme3.7->jme3.9 will not have these features (assuming I only develop render paths, global illumination based on FG, without developing these features for the old JME3 pipeline), so JME3 users cannot get these features immediately either, but I hope to update parts of the new features with each JME3 release, instead of keeping everything in JME4.
Ultimately, my motivation is: I hope JME3 users can gradually experience these new features in jme3.7, jme3.8, etc (of course they can clone my repo to use immediately instead of waiting for jme3.7, jme3.8 releases), rather than being told: the jme3 core currently does not have these features, but jhonkkk-gi.jar, jhonkkk-renderpath.jar, jhonkkk-fg.jar, jhonkkk-vrs.jar these third party libraries provide the new features, they may completely override and replace jme3-core in some future version, but no one knows when this “future” will be merged into jme3-core…
To repeat: I hope JME3 users can gradually experience some new features with each new jme3 release, rather than expecting them to use jhonkkk-xxx.jar libraries first.

I’m very sorry, I just want to enhance the existing JME3 in a “gradual” way, rather than having jhonkkk.xxx.jar first. I completely understand everyone’s suggestions.
But as I said at the very beginning, some code can be separated into libraries to support certain features, but some are pre-embedded codes for gradual refactoring, and I don’t want to break the existing application architecture. I hope the most reasonable transition would be: jme3.7 → jme4.0, the application layer only needs very few code changes to upgrade and use, and can maintain both old and new architectures at the same time. This should not break anyone’s projects (because they have the right to choose enabling old or new pipelines with very little code, the old pipeline will be fully compatible with old code, and will be gradually deprecated in the future), while for me, using jhonkkk.xxx.jar first would be more costly than Plan A (at least for me).
Also, choosing the jhonkkk.xxx.jar approach likely means “yet another JMB” kind of third party code framework or tool. Without the constraints, reviews from the community, the motivation of the author (me) would likely decrease, because these are just jhonkkk’s xxx.jars instead of “core” functionalities (although some say the jhonkkk xxx.jar codes may be merged in the future, but I think pre-embedding some code first and enhancing gradually should not conflict, and the new features can be turned off via switches)…
Anyway, I agree with the community’s final suggestion in the end.

[VR]

I don’t think there is anything wrong with jhonkkk’s approach. The old and new architectures can coexist, and can be turned off with a switch when unstable (jhonkkk has explained this). Also, the existing old jme pipeline will not conflict until the old pipeline is fully deprecated in the future.
I think one concern people have here is that jhonkkk may leave halfway and no one maintains the pre-embedded code.
I see jhonkkk’s attitude and efforts towards the community. I don’t think he just got excited for a moment and only made some WIP code. I believe he started this work 2 years ago, then left the community because of busy work, and came back; I believe he does want to improve the existing Jme3 architecture and add new features. Even if jhonkkk leaves the community halfway, since his code can be turned off, it should not affect the old engine pipeline.