[8Keep]

Add a separate jme3-benchmark module for bounding volumes, LightList updates/removal/sorting, and GeometryList clearing. Sort cases cover mixed lights, sorted/reversed/random inputs, and retained capacity. Update cases cover filters rejecting none, a quarter, or all local lights.

The module is only included when a benchmark task is requested, so it stays out of normal builds and published artifacts.

./gradlew :jme3-benchmark:jmh -PjmhArgs='-l'
./gradlew :jme3-benchmark:jmh -PjmhArgs='<JMH options>'

Some baseline results from this machine (i7-11800H, Fedora 44, Temurin 25.0.4):

Benchmark	Case	ns/op
BoundingBox.distanceToEdge	inside	2.01
BoundingBox.distanceToEdge	outside	2.42
GeometryList.clear	64 geometries	19.86
GeometryList.clear	1024 geometries	137.08

These baseline samples used JMH 1.37, one thread pinned to CPU 2, a 256 MiB heap, three forks, and 5 warmup / 8 measurement iterations of 300 ms. LightList comparisons are in #2784.

Normal project configuration excludes the module; compilation, benchmark listing, and the benchmark cases pass.

[gemini-code-assist]

Code Review

This pull request integrates JMH benchmarking into the jme3-core module, establishing the build infrastructure and adding benchmarks for bounding volumes, light lists, and geometry lists. Feedback suggests expanding the benchmark source set's classpath to include main runtime and test output dependencies to prevent potential compilation or runtime errors. Additionally, a more robust modulo-based offset calculation was recommended for the light list sorting benchmark to support arbitrary light counts.

[github-actions]

🖼️ Screenshot tests have failed.

The purpose of these tests is to ensure that changes introduced in this PR don't break visual features. They are visual unit tests.

📄 Where to find the report:

• Direct Download: screenshot-test-report
• Alternatively, go to the failed run summary > Artifacts > screenshot-test-report
• Download the zip and open jme3-screenshot-tests/build/reports/ScreenshotDiffReport.html

⚠️ If you didn't expect to change anything visual:
Fix your changes so the screenshot tests pass.

✅ If you did mean to change things:
Review the replacement images in jme3-screenshot-tests/build/changed-images to make sure they really are improvements and then replace and commit the replacement images at jme3-screenshot-tests/src/test/resources.

✨ If you are creating entirely new tests:
Find the new images in jme3-screenshot-tests/build/changed-images and commit the new images at jme3-screenshot-tests/src/test/resources.

Note; it is very important that the committed reference images are created on the build pipeline, locally created images are not reliable. Similarly tests will fail locally but you can look at the report to check they are "visually similar".

See https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-screenshot-tests/README.md for more information

Contact @richardTingle (aka richtea) for guidance if required

[riccardobl]

I think we should move all benchmark to a dedicated jme3-benchmark module, so that it is easier to separate them from the actual engine source code.

[8Keep]

Should be good to go now. @riccardobl there's something going on with graal in libjglios in the ci recently. I assume it's unrelated to this pr?

[riccardobl]

The only problem left here is that the jme3-benchmarks module is going to be included in the release zip and published to maven central.
I suggest to include it in settings.gradle only when the jmh task is launched, similar to what i did for ios examples:

jmonkeyengine/settings.gradle

Lines 29 to 36 in 032a493

	def isIosExamplesTaskRequested = {
	gradle.startParameter.taskNames.any { taskName ->
	taskName == 'runIosExamples'
	|| taskName == ':runIosExamples'
	|| taskName == 'jme3-ios-examples'
	|| taskName.startsWith(':jme3-ios-examples:')
	|| taskName.startsWith('jme3-ios-examples:')
	}

[8Keep]

Sorry for the delay. Fixed

[riccardobl]

@copilot resolve the merge conflicts in this pull request

[8Keep]

Rebased and whatnot

[riccardobl]

Thank you!

[jaime-jmebot]

The all case marks every local light as global, but world.update() filters those out and leaves the world list empty. That means this parameter measures only the empty-result path rather than updating a world list with all lights rejected; please make the filter scenario explicit and ensure the intended fraction is what the benchmark measures.

[jaime-jmebot]

• The benchmark module is cleanly isolated from normal project builds.
• One filtered-update parameter currently measures an empty output list, so the intended filtering comparison needs clarification/correction.