jME4 Development

ItsMike54 · March 13, 2020, 10:53pm

I’ll work from there. I’m pretty much thinking about working from the core lib out. You mentioned removing the particle lib from the core, redoing the terrain lib, physics, and javadoc. From what I’ve seen there are already great contributions to help with these, such as your Minie Physics and @glh3586’s particle monkey. If you agree with this being the best route, I’m thinking of simply working these into the new engine to replace what we currently have.

Edit: And I do plan on having the new features implemented as time runs on. I also am going to release my updates per every milestone I reach, and release it on github so others can work on it too. This will definitely require a team working on it

tlf30 · March 13, 2020, 11:16pm

I also have to agree that it would be best to work from master, many things have been changed and my branch is very out-of-date.

ItsMike54 · March 14, 2020, 12:42am

Well I’m going to do what you did and and start with doing rebranding and making some basic changes to the engine. But I’m glad to see more people working on this now.

ItsMike54 · March 14, 2020, 11:52am

What tools do the developers use to build projects with? Is it Maven or Gradle, or something else?
I’m trying to make sure I’m getting started the right way.

Also

Good, I’ll try to tap into his shader knowledge here soon.

pspeed · March 14, 2020, 2:09pm

Gradle.

This makes it sound like you’ve never built the existing engine before. That would be the first place to start, really. If you completely ignore what’s come before then you probably won’t get very far.

ItsMike54 · March 14, 2020, 2:10pm

Thanks, I’ve done work on the engine but not using any such tools. I’ll install and get to work

oxplay2 · March 14, 2020, 2:17pm

if i remember correctly:

clone JME repo using SDK with gradle(or via command line having git and gradle)
clean and build
run some tests to see it work.

thats the start point

ItsMike54 · March 14, 2020, 2:18pm

Ok, I’ll follow that order, thanks

oxplay2 · March 14, 2020, 2:20pm

generally its also here:

github.com

jMonkeyEngine/jmonkeyengine/blob/master/CONTRIBUTING.md#building-the-engine

# How to contribute to jMonkeyEngine

First and foremost, you have to familiarize yourself with Git & GitHub. Dig through 
[help.github.com](https://help.github.com/), [try.github.io](http://try.github.io/) and the [gh cheat sheet](https://github.com/tiimgreen/github-cheat-sheet/blob/master/README.md) if these are new topics for you. If you'd like to contribute with something other than code, just tell us about it on the forum.

## Communication

Communication always comes first. **All** code changes and other contributions should start with the [forum](http://hub.jmonkeyengine.org/). Make a thread to explain your change and show us the important bits of your code. If the code is too long to be posted within the forum’s code tags, please paste your code in a Gist or pastebin and link to the submission in your thread. You are required to register on our website in order to create threads. (We do support login via GitHub though).

### New Contributors

Check out the [Projects](https://github.com/jMonkeyEngine/jmonkeyengine/projects/1) tab, where the team has prioritized issues that you as a new contributor can undertake that will familiarize you to the workflow of contributing. This highlights some issues the team thinks would be a good start for new contributors but you are free to contribute on any other issues or integration you wish.

When you're ready to submit your code, just make a [pull request](https://help.github.com/articles/using-pull-requests).

- Do not commit your code until you have received proper feedback.
- In your commit log message, please refer back to the originating forum thread (example) for a ‘full circle’ reference. Also please [reference related issues](https://help.github.com/articles/closing-issues-via-commit-messages) by typing the issue hashtag.
- When committing, always be sure to run an update before you commit. If there is a conflict between the latest revision and your patch after the update, then it is your responsibility to track down the update that caused the conflict and determine the issue (and fix it). In the case where the breaking commit has no thread linked (and one cannot be found in the forum), then the contributor should contact an administrator and wait for feedback before committing.
- If your code is committed and it introduces new functionality, please edit the wiki accordingly. We can easily roll back to previous revisions, so just do your best; point us to it and we’ll see if it sticks!

This file has been truncated. show original

mitm · March 14, 2020, 8:10pm

Here is the setup stuff.

See Learn more here… Optional.

If you have problems with whatever you pick, let me know please.

ItsMike54 · March 15, 2020, 12:15pm

So far, I’ve removed some of the deprecated methods to clean things up. And as far as Vulkan, I have it so that one can specify Vulkan with
setRenderer(AppSettings.LWJGL_VULKAN11)
My next step is to allow a Vulkan instance to be created.

But as far as OpenGL is concerned, would we all agree it is time to remove JOGL/JOAL?

It is not near as popular as LWJGL, at least among our current community.
It dosen’t have bindings for Vulkan.
And its not exactly meant for gaming, unlike LWJGL which is.

I think at this point its another library in addition to LWJGL, and its not going to help us with Vulkan or anything else at least for the time being.

Physics
This is more specifically for @sgold, would you agree to having Minie replace jbullet/native-bullet completely?

GUI:
How much would we all agree to switching our GUI system to @pspeed’s Lemur? I think would be much better option as it far simpler and easier for beginners to use.

Other Projects:
These are the current suggestions I’ve found so far

github.com/tlf30/jme4

Roadmap

opened 12:21AM - 02 Sep 19 UTC

tlf30

1. Prepwork/Postwork * [x] Re-brand to JME4 * [ ] Remove all deprecated libr…aries/classes/functions from jme3 * [x] Remove `jme3-jbullet` * [x] Remove `jme3-lwjgl` * [ ] Remove `jme3-blender` * [ ] Remove `jme3-bullet*` replaced with Minie #9 * [ ] Remove old animation system * [ ] Format all code to a common format (POSTWORK) * [ ] Create a `JME4` issues tag on GitHub (POSTWORK) * [ ] Create a `4.0` branch on GitHub (POSTWORK) 2. JDK 11 ~~* [ ] Move to Gradle 5~~ DONE IN JME3 * [ ] Implement java 9+ modules 3. Vulkan Support * [ ] Add abstraction layer between the rendering engine and the rest of jme * [ ] Abstraction layer tests * [ ] Get OpenGL working in the new rendering layer * [ ] Get Vulkan working in the new rendering layer * [ ] Add basic Vulkan shaders * [ ] Vulkan tests 4. Platform Support (need to get working in JME4) * [ ] Windows * [ ] Linux * [ ] OS X * [ ] Android * [ ] iOS 5. Other JME4 Projects * [ ] Rewrite serializer ~~* [ ] Breakout jme-examples (see #7 )~~ DONE IN JME3 Things to take into consideration when planning this roadmap: * This JME4 will cut support for JDK 8 * There is a laundry list of items that we may or may not want to consider here: https://github.com/jMonkeyEngine/jmonkeyengine/issues/198 * If there are any changes not being implemented due to breaking compatibility with previous builds, this is the time to make those changes. About the SDK At this time it is *NOT* within the scope of JME4 to prepare a SDK based on Netbeans 10+. If someone wants to do this, we would welcome it with open arms, but it will take a massive amount of work, and we already have a lot to do just getting JME4 ready.

Let me know what you all think

pspeed · March 15, 2020, 1:53pm

Every time you embed a library in “core”, you are saying “Gee, I don’t like the convenience of having this library get updates often… I’d rather have bugs stick around for 2-3 years before they really get fixed.”

JME should be MORE modular, not less. Just something to keep in mind.

But I guess if you treat it like nifty, where the real library develops separately and JME just decides on including a particular version from time-to-time then it mitigates that.

…but then it’s also not much different than just including a dependency in the build.gradle file.

ItsMike54 · March 15, 2020, 4:33pm

I hope I didn’t phrase that incorrectly, but I didn’t mean shove everything into core lib.

I meant Lemur as a drop in replacement to Nifty and Minie to Bullet, and they be right where Nifty and Bullet are right now, outside the core lib.

sgold · March 15, 2020, 4:56pm

Based on my experience with issue 796 it appears JOGL is no longer supported in JMonkeyEngine. I say delete it.

Yes.

pspeed · March 15, 2020, 5:23pm

If you meant, make a directory for it in jme repo… then it’s the same thing, to me. Monthly releases because once-every-three-year releases.

If you mean, add a dependency line in some build.gradle files that need a UI then I’m fine with it and I’m not sure it needs much discussion.

ItsMike54 · March 15, 2020, 5:26pm

I meant the first, make a directory in the repo to replace Nifty as it is a lot easier to use. Now if there is a problem with that, let me know.

pspeed · March 15, 2020, 5:28pm

Problem: I can release Lemur whenever I want to now.

Make it a part of JME then Lemur can only get updates once every three years or so.

JME is already too big. Half of the things need to be moved out to their own projects… or at least made separately releasable.

Nifty needed its own integration layer which is why it has a project in our repo… but the nifty jar was always separate. Lemur requires no such integration layer.

ItsMike54 · March 17, 2020, 12:39pm

So first update on my progress. I’m writing the rendering engine from scratch, which sounds very difficult, but its working so far.
I can almost officially say the blue-box-on-black-background “BasicGame” Application is fully capable of being rendered with the Vulkan renderer

There is not yet a guiNode, so 2D text and pictures cannot yet be rendered, but 3D models can be loaded and rendered with textures.

As far as if the OpenGL shaders can be used with Vulkan, I have not yet tested it. If worst comes to worst and Vulkan requires its own seperate shaders, I’ll try to make a collection of Vulkan shaders that I’ll include with this project when I finish it.

ItsMike54 · March 17, 2020, 8:50pm

I have a question about the current jme3 setup as I want to make sure I get this right for jme4. How exactly do the Android and iOS libs work? As far as I see, there are no LJWGL natives for any mobile platforms and that made me very curious. I could definately use an expert here.

ItsMike54 · March 18, 2020, 8:47pm

I want to state the fact that only obj models can be loaded, so no j3o. When I finish this, somebody can add on j3o support at their own desire. But what is the point of having j3o in the first place? To me at least, developers would prefer to handle all the files in their own native format and not need to convert them to something “proprietary” that is very limited as far as accessibility.