Just wanted to jump in to say “thank you” for your contribution, and looking forward to your enhancements to jme! 
Also noteworthy is your mature and polite attitude toward the community (in the past we got several geniuses with terrible social and collaboration skills) 
For a moment there I was thinking that you are referring to me. But then I realized that there was AND operator. Genius && terrible social skills && collaborations skills. Fortunately I’m not genius, so…
Jokes aside… Exactly what Pesegato said and also thanks for the active touch for those reviewing the PR.
@zzuegg I took some time today to fix the top light culling issue and flickering problem you previously mentioned：
This is a multi-light test of PBRTerrain, rendering 1000 PointLights at 1600900 resolution. Below are results for Forward:
Deferred：
Tile-BasedDeferred（**Note that for Tile-BasedDeferred the TileSize can be 32, 64, 128 (powers of 2) depending on your current screen resolution and total light count. Adjust this value until optimal performance is reached - too low or too high tileSize can both result in suboptimal framerates (too high or too low). The current tileSize is set to 64 which is configured for 1600900 resolution with 1000 point lights.**）：
I found that JME currently has poor support for dynamic textures, which led tile-based Deferred to upload larger texture sizes to the GPU when reallocating texture memory. However, I tested the glTexSub interface to adjust sizes dynamically, and while frame rates were very stable, unpredictable tile flickering occurred. I will implement optimizations with dynamic sizing and SSBOs as data containers in a future PR.
hi, 
@sgold @RiccardoBlb
I have supplemented a large number of core comments for the core module files, added complete JME license information for each java file, and fixed some code based on the valuable suggestions provided by @codex . I have locally tested a large number of examples codes which basically work normally. I think this PR is ready to change from “Draft” status to “Review” status for final review.
If there are still any issues, please let me know to avoid keeping this PR in draft status for too long. Thank you. 
Hi @JhonKkk
Is it possible for you to make your enhanced JME engine available for consuming via Gradle? I would like to try testing it in my product.
You can just fork the branch. And then use it or hook it up i.e. jitpack. Or just do it straight from the branch too without forking…
Looks like it is the master branch: GitHub - JohnLKkk/jmonkeyengine: A complete 3-D game development suite written in Java.
I did not do that, I think you can try @tonihele approach.
That is awesome result
13 fps into 600+
for more open-space map lights were fps-killers, so with this changes could no worry about lights, and have for example nice distant city with lights.
I will further optimize tile-based Deferred in future PRs to provide higher frame rates. I just tested on some 2k resolution machines with friends (rtx2070, rtx3060, gtx1060) and they achieved quite high fps overall (400+), so I think this 1.0 version should be sufficient for some current needs. I will continue working to improve it in subsequent PRs.
On thing to discuss in general would be the light handling. If you did not pull a magic trick out of your hat, all modern lighting techniques do not support “per spatial lighting” while in jme it is supported. this would be something where behavior changes.
Leave it as it is, or changing the way stock jme does the light culling are the only options here.
@JhonKkk just to mention here - please treat this post a little as offtopic maybe
I belive Terrain is one of most important parts for many games (even some of 2d view ones).
im using PBR terrain(JME one but edited) with Texture arrays and Occlusion Parallax Mapping(Awesome Riccardo work):
https://library.jmonkeyengine.org/#!entry=16283%2F571e75d2-d9c6-4f3f-8b99-3c717bbf42bd
it would be cool to implement parallax occlusion mapping into PBR one while still having it working for required GLSL version.
Because for Array need #extension GL_EXT_texture_array : enable that i remember requre GLSL330 while JME one starts from GLSL150 GLSL100
So skip this part to maintain GLSL backward compatibility.
Sadly because its very cool using:
TextureArray PhongTextures
TextureArray NormalmapTextures -LINEAR
TextureArray ParallaxmapTextures -LINEAR
in j3md, but we cant for stock one.
(tho if we would make one Terrain version for higher GLSL then why not)
But we could add Occlusion Parallax into JME Advanced PBR Terrain
This is GLSL110 GLSL150 compatible.
I can share what i have done in my shader tho its not perfect ofc.(tho i already shared in some topic before)
Blending part is most problematic for frames. But PhongTextures and NormalMaps are already blending there, so adding ParallaxmapTextures should not cause so big issue i guess. (and ofc using #ifdef should make it same fast if not using oc-parallax)
Im not sure how Tile Deferred work exactly, but maybe even it could be possible to Decide what textures should blend (instead blending 4+, or even 12 textures for each pixel)
You are much more experienced than me in Shaders there.
Its just personal wish i hope someday there would be perfect Terrain JME Stock shader out there.
Some previous screenshot i made:
here what is cool that can even use AO or moisture based on oc-parallax value:
here is what Riccardo had using (also looking cool):
It is used in many popular games (even now Starfield as i noticed) but also older ones like Hunt Showdown:
Ofc i can share current shader (tho i got AO and moisture addons to ao-parallax there)
Your suggestion is to either completely overhaul JME’s lighting management or keep it as-is, correct? Please let me know if my understanding is incorrect. Thank you. 
It is only one of the things not supported by any deferred/forward+ technique. It has been implemented for performance reasons with the current jme lighting system.
I would probably keep it as-is. But for everyone using an AmbientLight as model highlighter this is introducing breaking changes.
I don’t think I will add any additional new features in this PR (to keep this PR focused), but your suggestion is interesting. I think any features added to the core should aim to benefit the majority of JME users. I believe others (such as @yaRnMcDonuts ) may also be interested in this area, so I can progress this in a future discussion or PR.
so something like this?
in the repositiories section add:
maven { url "https://jitpack.io" }
in the dependencies section replace:
implementation 'org.jmonkeyengine:jme3-core:3.5.2-stable'
with:
implementation 'com.github.JohnLKkk:jmonkeyengine:master-SNAPSHOT'
should I also change all other JME dependencies to 3.6.1 stable or can I leave it in 3.5.2 stable?
i belive you can also use something like:
repositories {
flatDir {
dirs '../libs'
}
}
and put builded JME Jhon fork JAR packages there.
I would change them all. I don’t know how compatible they are against different versions nor have I actually looked what packages have actual changes in this fork. So I would just use the whole fork as my sole source.
To be honest, I may have misunderstood, so please correct me if I’m wrong. 
Let me re-understand your point, for example, there are 3 lights in the view frustum, the first two lights only affect objects under NodeA, the third light only affects objects under NodeB. Now, in DeferredShading, objects under both NodeA and NodeB are affected by all 3 lights. You want to keep the original JME3 lighting filtering by “spatial/node”? Actually this is feasible under deferred rendering, but I won’t implement it in this PR either. I’ll add it to the todo list (to avoid forgetting…).