Roadmap for Future Release

[erlend-sh]

This is our open roadmap for a Future Release. In other words, features listed here are not being actively worked on nor planned for inclusion in our next upcoming release, which is v3.1.

If you have started work on any of these items, please:

1. Start a new issue-ticket for it (usually labeled enhancement)
2. Edit this doc and suffix the item description with your new ticket's ID number.
3. If the item can feasibly be targeted at v3.1, move the item from this list to the v3.1 roadmap: Roadmap for v3.1, Upcoming Release #199

Legend

Bold - Must have for next compatibility-breaking release.

Infrastructure Improvements

• ???

Core Engine Improvements

• ???

SDK

• Instead of creating a Blender3D replacement - focus on creating tools people will need
• Model / Animation / Scene Viewer w/ 3-light setup
• Generate bullet collision shapes
• Generate jME3 collision tree
• Generate tangents
• Generate LOD levels
• Importing a model should automatically give you options to optimize it

com.jme3.app

• Gut out SimpleApplication and implement its functionality in Application or separated into AppStates.
• Replace it with QuickStartApplication that just adds certain (common) AppStates which implement the current features of SimpleApplication.
• Remove all protected variables in Application / SimpleApplication. Add methods to achieve the functionality as necessary.
• Add Application.getWidth() and Application.getHeight() which simply returns the values from the context.
• Make the PauseOnLostFocus value set to false by default, since it causes many applications to work incorrectly.
• Kill Applet support
• SettingsDialog
  • Allow user to select the type of context (LWJGL-OpenGL1, LWJGL-OpenGL2, JOGL-OpenGL2, etc), if the AllowContextSelection app settings is true.

com.jme3.post

• ???

com.jme3.font

• Fix BitmapFont, must have all the features the current one has, but without the bugs.

com.jme3.app.state

• Add a new interface called SystemAppState which contains the following methods. Application is responsible for calling them to inform SystemAppStates of context callbacks.
  • lostFocus()
  • gainFocus()
  • reshape()
• Add a new abstract class called FixedStepAppState in which all TPF callbacks are constant (e.g. 1/60), and if needed, are called multiple times per frame.
• Remove AppState.stateAttached and stateDetached as they cause confusion among users. The following methods should be present on BaseAppState which is an abstract class: onInitialize, onDestroy, onUpdate, onRender, onPostRender methods.

com.jme3.system

• Add new properties to AppSettings:
  • Boolean: “Resizable” - Whether the JmeContext.Type.Display is capable of being resized or not (by dragging the edges of the window). Such resize attempts will cause the SystemListener.reshape() callback to be invoked with the new display resolution. This capability is already available in LWJGL and JOGL.
  • Boolean: “AllowContextSelection” - Whether the user can select the context implementation in the SettingsDialog
• Fix existing properties in AppSettings:
  • Object[]: “Icons” - This should be an array of strings (instead of BufferedImage) specifying image files in the classpath. Each image corresponds to an icon of a particular size. The icon is used when displaying the application in the task bar, task manager, window icon, etc (platform specific).
• JmeContext.getJoyInputs() - New method that returns an array of JoyInputs in case multiple implementations of joysticks are available.
• JmeContext.getWidth(), JmeContext.getHeight() - Returns the width / height of the context. The AppSettings width / height values should still be updated by the context though when they change.
• JmeContext.getCurrentDisplayMode() - Returns the current display mode on the system. Can be called at any time, even before JmeContext.start().
• JmeContext.getFullscreenDisplayModes() - Returns all supported fullscreen display modes. Can be called at any time, even before JmeContext.start().
• Add new “semi-paused” mode to JmeContext where it will continue calling SystemListener.update() at about 5 - 10 FPS, and isRenderable() is set to false so that no rendering is performed. This mode of rendering shall be used when the application is not in focus, unless PauseOnLostFocus is set to true, in which cause the same behavior is exhibited except SystemListener.update() is not called.

com.jme3.audio

• Replace SeekableStream with SeekableInputStream that extends InputStream and adds two new methods:
  • seek(long position)
  • getPosition()
• Replace the OGG/Vorbis decoder implementation with one that supports seeking properly, i.e. either JOrbis (LGPL) or libtremor (native).
• Surround audio data for 4 channel and 6 channel audio data formats:
  • If AudioData getChannels() reports 4 or 6, use OpenAL Soft’s extension AL_EXT_MCFORMATS to specify a multi-channel surround format such as AL_FORMAT_QUAD16 or AL_FORMAT_51CHN16.
• Fix looping for streaming-type sounds by seeking to 0.
• getDuration() should return a proper value even for streaming audio by retrieving it from the header.
• New interface: AudioEventListener
  • audioStateChanged(AudioState)
  • Called when sound starts playing or stops playing
• Currently audio is not “culled”, meaning, far-away sounds are still getting processed even though they are far away from the listener.
• The Listener class must be removed, its functionality is already performed by the Camera class.

com.jme3.input

• Create new CollisionChaseCamera that would cast a ray to determine a safe distance to place the camera at so that only the inside of the scene is visible. Many solutions have already been made available on the forum.
• ChaseCamera and FlyByCamera must become AppStates.
• Move away from event-based input to data based. As in, requests can be made to a binding to acquire its current value. This allows easier implementation of combo keys, etc.
• FlyCam: Add smooth rotation / movement, demo will look much better.
• In AwtMouseInput, the coordinates are returned inverted - origin top left, whereas in other implementations they are returned - origin bottom left.

com.jme3.asset

• Unfortunately the asset cache needs to be re-written again …
  • Remove the garbage collector based caches and replace them with LRU based cache
  • Allow user to specify their own implementation or go with the default LRU
  • Expose the methods addToCache / removeFromCache / clearCache in the AssetManager interface since most people will need to use them anyway.
• Allow users to process assets by registering AssetProcessors for specific subclasses of AssetKey. E.g. AssetManager.registerAssetProcessor(Class<? extends AssetKey>).
• Add built-in multithreaded loading of assets via a new method
  • Future loadAssetLater(AssetKey)
• Support importing FBX and Collada format via fbx-conv (NOTE: C/C++ based):
  • https://github.com/libgdx/fbx-conv
• Support importing many other formats via AssImp (NOTE: C/C++ based):
  • http://assimp.sourceforge.net/
• Make sure all android assets are stored inside the APK under the “assets” folder. Storing them in the Java classpath is known to be unreliable.
• Fix OBJ loader complaining about “g” and “o” statements .. Many people think the model failed to load - on second thought, consider deprecating OBJ completely.
• Need “perfect” art workflow from Blender to jME3. The current blender importer does not satisfy this requirement and never will due to its fundamental flaw of having to import the blend format and its dependence on blender concepts. E.g.: improve the blender2ogre exporter so it properly converts materials. Or create a specialized exporter that generates jME3 material files.

com.jme3.animation

• Generate a bounding volume for every animation and set it when that animation is played.

com.jme3.scene

• Use Red-Black tree for collision detection instead of Bounding Interval Hierarchy (BIH) tree. RB is better suited for dynamic updates than BIH.
• Really need to have collision flags to satisfy which Spatial can collide with which. This is a must have for the next version.
• LightSortControl - A type of Control that propagates lights down from a node to its geometries, and performs light-culling and sorting by influence / priority.

com.jme3.bullet

• Standardize scaling for collision shapes so that it is clear which types of bodies support it or don’t.
• Remove jbullet support in favor of native bullet. Put all resources into improving and supporting native bullet.
• Create a proper btStridingMeshInterface for a jME3 Mesh instead of the mess we have right now.
• Serialize the 100~ point cloud for convex hull collision shapes instead of serializing the mesh itself and regenerating the point cloud each time.
• Add material callbacks, so you can play a sound when one thing hits another
• New call: RigidBodyControl.setActivationMode(ActivationMode) taking an enum:
  • ActivationMode.Auto - Activation state is determined automatically, e.g. based on current velocity.
  • ActivationMode.Always - Body is always active (physics always performed)
  • ActivationMode.Never - Body is disabled (no physics is performed)
• Then remove RigidBodyControl.setEnabled(boolean) and use setActivationMode to enable / disable it instead.

com.jme3.shader

• Shader modules and interfaces (TBD) - Perhaps need to have the capability for materials to “implement” so-called material interfaces. The user can choose to activate the interface. E.g. Unshaded can claim to implement Fog and HWSkinning - these calls occur in the shader but have no functionality unless the relevant interface is activated.
• Issue where setting parameter in Control to shared Material leaks onto other models .. (HW skinning). Need alternate approach?

com.jme3.effect

• More flexible particle system that supports mesh animations, color ramps, scriptable particle animations, particle ribbons, etc.
  • Mesh particles can be done via the new geometry instancing system
  • For triangle particles, perform billboarding on the GPU
  • For point / triangle particles, use a geometry and vertex shaders to update the particles

com.jme3.renderer

• Implement seamless cubemap mipmapping by default if supported
• Current queue system uses depth range and modifying camera transforms to implement the GUI and sky buckets. Is there an alternate way of doing this? Maybe Gui3D bucket which does not set depth range but has a -1, 1 ortho transform.
• Deprecate BGR formats

com.jme3.util

• Improve SkyFactory documentation and make it more flexible ..
• Remove the useless “sphereMap” parameter.
• Gamma-correct mipmap generator
  • Take input sRGB texture
  • Convert to 32-bit float and then linearize
  • Perform bicubic blending to generate samples
  • Convert back to sRGB colorspace, then to 8-bit with rounding
  • IF the input texture is a normal map, then
  • Skip sRGB <-> linear conversions
  • Unpack normal
  • Normalize
  • Downsample
  • Normalize result prior to writing into mipmap level (?)
  • Pack normal

[elect86]

Hi,

if interested, we are working on a jvm port of Assimp here

[empirephoenix]

Already noticed you guys, and saw that you have some interesting parts that could be used for jme :)
My next plan is to write a adapter for the imgui port

[elect86]

We worked recently to make it work with libgdx thanks to a user who needed and cooperated and I'd like doing the same for jme

Don't hesitate opening an issue for that :)

[g-amador]

Hi, (this is a suggestion) I propose that there is an incorporation in the JM4 engine roadmap.
Introduce a low code module to allow to quickly build low code games.
Personally what I suggest is a module that runs SNAP! or equivalent https://snap.berkeley.edu/ and then exports a JAR capable of interpreting or running the .xml that SNAP! allows to export.