High-quality test and example scene

[codex128]

TestScene is a high-quality and configurable PBR scene that can quickly and easily be set up for any tests or examples.

The scene was created with only the following setup:

private class TestApp extends SimpleApplication {
    
    private static void main(String[] args) {
        new TestApp().start();
    }
    
    @Override
    public void simpleInitApp() {
        
        JmeUtils.setDefaultAnisotropyLevel(this, 8);
        
        TestScene.setupSimpleApp(this);
        PhysicsSpace space = TestScene.setupPhysics(this, false).getPhysicsSpace();
        
        TestScene scene = new TestScene(assetManager, viewPort);
        scene.setPhysicsSpace(space);
        scene.setSubScene(TestScene.PHYSICS_SUBSCENE);
        rootNode.attachChild(scene.load());
        
    }
    
}

Current features:

• Scene length and width is configurable so it can fit any test or example.
• Automatic lighting and shadows that can be disabled if desired. Shadow map size and number of splits are configurable.
• Automatic filter effects (SSAO and Bloom) that can be disabled if desired.
• Performant physics scene.
• Automatic light probe generation with EnvironmentProbeControl.
• Configurable image-based skybox.
• ...and a more small bells and whistles.

Todo:

• Get a nice skybox. The ones jme has already aren't good enough, in my opinion.
• Create more subscenes. There is only a small physics subscene right now.

TestScene is currently part of the jme3-examples package, which is normally not built for releases, I believe. I think it would be best if it was moved to where end users can access it easily. Does anyone have any ideas for this?

This PR also includes JmeUtils, to which I've added several methods for shadow renderer/filter creation and anisotropic filtering. I can remove this class, but I think it would be beneficial to have a class or two that helps streamline development like this class does.

What do you all think?

[capdevon]

IMO, the jme-core module should contain only the essential engine functions. This would allow users to create custom utility libraries that perfectly fit the needs of their projects. After all, user freedom is a fundamental principle of JME!

By keeping utility classes separate, we ensure that they can be easily tested, updated, and maintained without impacting the main engine. This is especially important considering the long release cycles of JME. Utility class bugs can be fixed much more quickly in external libraries than waiting for the next engine update.

So, let's empower users and keep the core engine lean!

[codex128]

This PR is designed for use in official JME examples and tests, so I can't move it to an external library. What do you suggest?

[capdevon]

This PR introduces two new classes to the jme-core module: NormalQuad and JmeUtils.

1. NormalQuad:

There are already existing classes like Quad, CenterQuad, and RectangleMesh. I don't know if another NormalQuad class is needed.

2. JmeUtils:

Since it's customized to your specific needs, it might not be universally applicable to other users. There are hundreds of classes like this on github and they should not be in the core module.

---

TestScene:

The TestScene class looks a bit complex for general use and contains many options that you have customized on the .blend and .gltf scene file. I believe in keeping example classes clear and easy to understand.

Consider that there are already 2 open Issues to improve the jme3-examples module: https://github.com/jMonkeyEngine/jmonkeyengine/issues/2145

[codex128]

TestScene

There are two problems that need to be solved:

1. The engine examples are ugly.
2. Users new to JME are unable to make graphics that look good, simply because it is very difficult to do.

Solving these problems could greatly boost the confidence users have in their engine of choice, thus making them less likely to drop the engine when they inevitably hit a tough problem. TestScene is trying its best to fix these problems, and it would do a pretty good job, imo. It is taking a very complex problem and reducing it to a set of parameters that are frankly very easy to work with. If you have suggestions on how it can be made simpler, I'd be happy to hear them.

Also, I would argue that TestScene would actually make the engine examples less complex, because it would move all that messy boilerplate scene setup elsewhere. Of course, this would only be true if users were already somewhat familiar with what TestScene does.

NormalQuad

Ah, I was unaware of RectangleMesh. I will delete NormalQuad.

JmeUtils

Ok, I see what you mean, I will delete that also.

[neph1]

And please make it the default scene of all the examples. It would be especially nice to get rid of the ogre.xml scenes in jme3-examples.

[capdevon]

If you intend to go ahead with this PR, to improve code maintainability and facilitate review, consider using the Builder pattern for the TestScene class or a BaseAppState or something else. This would enhance its flexibility and readability. Including references to unused objects like Sky, ShadowRender, ShadowFilter, FilterPostProcessor, Filters, PhysicsSpace, LightProbe etc... in a class that extends Node, seems inefficient and is not a good example for novices. Consider removing these references or creating a mechanism to handle optional components.

Modifying 20 classes at once makes review cumbersome. Break down the changes into smaller, manageable pieces. Additionally, aim for a balance between utility methods and code exposure in TestScene class. While utility methods can improve code organization, excessive use can hinder understanding.

Examples should be stripped-down to highlight a single functionality. While aesthetics can be appealing, prioritize clarity and ease of understanding.

Edit: Alternatively, you can consider creating a couple of "new" test scenes with high-definition lighting and textures to show off the engine's capabilities.