mefisto94 / jme-discussion Goto Github PK

So, in order to see if everything even starts without an exception we could have a test harness where we'd launch the test, wait for 10-30s and then send an "escape" to the window.
If the launched application returns an exitCode of 0, everything is well. If a timeout happens or an exception is thrown (we might need to remove the AWT Exception Window there), the CI test fails.

Problem is: We need HW Accelerated Test Slaves. Still having such tests is good, because in the worst case, we can manually test these things after changes like a lwjgl version update etc.

This can be extended to support clever testing (checking pixels in certain render output, provided we control tpf for determinism, like for PBR to see if the color has changed due to a change in env probes or whatever).

There are quite a few issues with LWJGL3, most of which are our responsibility.
For instance: LWJGL3 now returns keyCodes and virtualKeys. JME changed the behavior on which ones to pick, but it's important to have both: Virtual Keys to support the Layout for a Chatbox/Text Input and KeyCodes for WASD to be where it usually is.

Another issue is Mac OS X and the Settings Dialog: Even when jumping through a few hoops it still doesn't really work reliably.

Settings Dialog 2: The AWT Refresh Rates are incorrect (or too correct) and thus crash when attempting to launch lwjgl3 in fullscreen.

We have a wide variety of pluggable GUI Systems and it feels like NiftyGUI is the less supported one but still it's in core.

My Proposal is to remove it out of core but maybe keep in under the jMonkeyEngine organization and submit it to the asset store. For users this probably not even changes anything (maven coords could be the same), but it's clear that this is a seperate thing can equal to the other GUIs and can have it's dedicated team.

This helps us getting the core to be more lightweight.

There has been talk about using json for the material system instead of a "home-grown" special syntax, which is harder to parse, especially for tools, and in history, was error prone already due to false parsing.

We don't have the sourcecode at hand (it's hard to come by) and even then we have noone willing to fix it and improve it. The only worth it has currently is to double check if this is a user problem or a library problem.

Another benefit is that it runs everywhere, where native bullet is compiled for android and desktop, but not for iOS and not for potential web content.

On @MeFisto94's request, I'll write down some stuff I find easier to do in Godot than JME. Do note though, I've only made a couple experiments in Godot, farm from the amount of experience I have with JME.

1. Scene Graph Editing

It can technically be done in the SDK, but quickly throwing together full scenes as wanted is almost impossible without coding in JME. The farthest the SDK can currently go IMO is fixing some orientations and materials on import. As long as you stay with Nodes and Geometries it's fine, but as soon as you go into lights, particles, sound... the SDK falls flat.

2. VR Support

Let's face it, JME-VR probably needs a complete rewrite.

3. Material Editing

I had the SDK one completely give up on me every so often, especially when writing custom shaders. It also has unnecessary left/right sliders in the non texture section of the material editor, which really annoy me for some reason. The fact that the material editor in the SDK is by default in a different tab than the scene composer and you can't have both shown at the same time doesn't help either, as PBR materials consist out of a lot of guesswork and seeing the changes on your intended model in real time is important.

4. Networking

Godot's networking system is higher level than JME's. I could never wrap my head around making a simple multiplayer room where multiple players can move around with just sending messages which I would have to write manually etc. In godot most stuff is a single RPC away. GDScript keywords for master/slave variables help a bit too.

This might just be a documentation issue though.

5. Animation

Godot comes with a full animation editor, almost like Blender, which allows keyframing of pretty much any number, including variables. Oh, and calling a function in your code on a predefined keyframe is cool as well.

6. Graphics

Global ilumination, SSR, a decent looking bloom, HDR, etc. JME just lacks in the eye candy department. Most filters JME has, are stuck in 2005.
I'm aware Riccardo is brewing a new pipeline, so the situation might improve in the future.

7. Environment

Setting up the environment in JME is cumbersome. Load a HDRI as skybox, then manually generate a light probe, then add an ambient light to fix the intensity. Or just do it in a single UI panel in Godot. Not to mention procedural skies in Godot.

8. GUI

I know it's not exactly comparable, as Godot was, until not too long ago, a primarily 2D engine, but in JME, making a GUI is a pain I rather avoid unless I'm making something I intend to publish. In Godot it's literally dragging a couple elements to the canvas. It's also a big difference that you can see your gui in the editor. In JME you have to launch your game, wait for it to open (which can get long when your game has a lot of assets to load), figure out your text is 3 pixels too far to the left, close the game, tweak the code, repeat. We literally had a launch argument in LSF which only loaded the GUI to minimize the wait.

For me, this results in different approaches to developing. In JME I just hardcode the values I want while testing, while in Godot making a GUI for setting them might even be faster and certainly much more flexible.

That's just some stuff I could remember from the top of my mind. I'm sure that when I dig in more, I'll find more stuff that I find better in Godot.

And while I'm at it. Please stop with the "well X feature can be found in a plugin from the asset store" mentality. There are some things people expects for a proper game engine to just have. Without having to download (unmaintained) plugins from third parties.

I think we should remove all the incomplete/broken model loaders from the core.
I would keep only gltf and obj.
Having so many choices confuses the newcomers, increases the code we need to maintain... and they don't fully work anyway.

See https://eleni.mutantstargoat.com/hikiko/2018/03/04/opengl-spirv/
TLDR is: When using proper (GLSL 450) openGL Shaders, we can cross compile them to SPIRV (and potentially ship it with a game) and the Graphics APIs should all support SPIRV ("compiled shader"), which can directly be evaluated by those.
This yields in faster speed as the drivers don't have to manually compile instructions and also maximum platform compatibility.

Projects like https://github.com/KhronosGroup/SPIRV-Cross allow SPIRV to be cross compiled to GLSL, HLSL (Direct X) and Metal (Mac OS X), so that even when SPIRV Extensions aren't available, one can use the native backends for shaders at least.

This is in particular interesting as Vulkan as a Backend also supports SPIRV

Paul Speed probably has the argument that unit testing doesn't help as the bugs evolve around the code that isn't unit tested.
I think that's a good thing then, we'll only have to ensure that the most important code is tested.

For instance I think raycasting and other scenegraph related things could make a good use of tests.
e.g. we had a bug where the returned bounding box was "null".
Raycasting a specific geometry and/or terrrain should be deterministic as should be the bounding box calculation, general transforms etc.

There are probably quite a few other ways.

Generally there are lots of places where we prevent the user from doing bad things.

A quite wished for feature here is the ConcurrentModificationException for the SceneGraph: A simple if !Thread.currentThread().getName().equals("jMe3-MainThread") before every SceneGraph Modification would help debugging those issues much much better, but would slow everything down.
This could be an assertion. As could be checking for non-uniform scale on non-root-nodes etc pp.

Note: The above shouldn't be implemented as is, because with proper locking accessing from another state is okay, as can this issue be caused by other things as well (forgetting to call the right updated methods on a custom viewport). Also I think a custom engine build with diagnostic logging on everything in the Spatial class with stacktraces might help more in that case.

Still there are quite a few things where assertions could happen over a NullPointerException or others.