Setting up as a new jme user

I’ve been reading through the documentation, but I’m still a bit confused as to what exactly the difference is between the SDK, the Engine, and the Gradle project.

Also, I was trying to set up the SDK to use OpenJDK11 (both from inside the IDE, and by modifying the jmonkeyplatform.conf as described in the documentation) but I’m seeing a ‘Fatal Error : unable to find java.lang’ message.
I’m using OpenJDK11 in non-jme projects with NB11 on Windows10, so I’m not sure what’s going on.

Can someone shed some light ?
Thanks !

The SDK: a customized distribution of Netbeans that comes with various tools for easier development

The engine: a bunch of .jar libraries that do the heavy lifting: loading your assets, rendering them, handling input, playing sound…

The gradle project: Uhh, which one? Both the sdk and the engine are gradle projects in architecture. I suspect that your own gradle project is meant in this context. If you have no idea about what gradle is, start here: Building Java & JVM projects

And since you mentioned Java 11 and NB 11, it is worth mentioning that the SDK is based on NB. NB version 8. It doesn’t support Java 11. You are stuck with Java 8 with the SDK currently. SDK based on NB 11.2 is around the corner yes…

So at the moment maybe your best shot is to use the NB 11 with Java 11 you are accustomed to. Just create a Gradle based project with references to the JME binaries. There was the official Gradle JME project example somewhere in the forums… Or the docs…?

Anyway, there are plenty of these around. For one example: OpenKeeper/build.gradle at master · tonihele/OpenKeeper · GitHub

@siska dont try make JME SDK use OpenJDK11, because it used embeded OpenJDK8. (well you can override it in SDK via file copy, but it will break SDK)

if you want version 11,

I would suggest you use Netbeans11(OpenJDK11) for Code(using gradle), and SDK for asset managing.(using ANT for assets project)

In gradle i use like this myself, in dependencies in gradle i have:

if(production){
    runtime project(':GameAssets')     // production
} else {
    runtime files("..//GameAssets/assets")  // development
}

im not sure if this page was created by @mitm or @jayfella

But i think on this start page should also be link to packages description.

for example what is package jbullet and what is native bullet, what is lwjgl and what lwjgl3, etc.

because even on start this 3 packages can be much too low amount for start(except blue box…)

Wow ! What a wonderful community !!!

@oxplay2 & @tonihele : Oh, so the JDK1.8 platform is really OpenJDK ? That’s fine too for now.

I’m also confused about the lwjgl/ lwjgl3/ jogl dependencies. Can I just pick whatever I like and everything will still work ? Or is there some setup involved as well ?
Also, @oxplay2, when you say ‘use the SDK for asset management’ : do you mean creating the model binaries etc ? Do you also create the scenes there, or is that through code ?

@grizeldi : I was referring to the one on the ‘quick start’ page (I didn’t realize there’s a bunch of options).

I would have put my reply to you in the above reply, but I’m only allowed to refer to 2 users (being new) =)

@oxplay2, when you say ‘use the SDK for asset management’ : do you mean creating the model binaries etc ? Do you also create the scenes there, or is that through code ?

I’m also confused about the lwjgl/ lwjgl3/ jogl dependencies. Can I just pick whatever I like and everything will still work ? Or is there some setup involved as well ?

You have 100% freedom.

  • You can use j3o converted models, but you dont have to (you can use .gltf or other directly too - it will just load longer)
  • You can use lwjgl(older version) or lwjgl3 that is newer Version - myself i needed newer for Shader GLSL 330+ as i remember.
  • you can use outdated jbullet(that is in Java) or you can use bullet-native(in C that is more “fresh”) or you can use Minie project(@sgold lib that seems best JME physics library)
  • you can create Scenes in SDK, but you can like me create scenes in Custom Editor using ECS entites. (myself i dont use JME Zay-ES, but you might be interested in it)
  • You can use ANT build or Gradle Build.
  • You can export models to a lot of formats(but i suggest Blender 2.8 GLTF export https://wiki.jmonkeyengine.org/jme3/external/blender/blender_gltf.html)

There are much more to say, but you have 100% freedom here.

even if something is not provided, you can fork Engine and do it yourself :slight_smile: (or add pullRequest for core-devs to add to official repo)

btw i suggested JME SDK assets project as ANT (yes for assets like testures/models/gui xml/sounds/etc) because SDK dont see assets properly as Gradle project.

Code i suggest in other IDE you like, as Gradle build project.

2 Likes

I don’t really understand the sentence. But I’m talking about Java versions. Whether you use OpenJDK or Oracle JDK, it is up to you. Yep, multiple implementations of the standard exists. The thing is that the IDE needs to support the version you want to use. Netbeans 8 doesn’t support Java 11. It think it just goes up to Java 8. Java 11 is the current long term support (LTS) Java version. Version 8 is still also supported for awhile, at least the Oracle JDK one.

@tonihele : I meant I don’t really care too much about what version of Java I’m using at this point. I just don’t really want to use the legacy Oracle jdk, because if I understood correctly, we’re no longer supposed to use that in commercial products …

One more option is to create regular maven project (if you’re familiar with maven) and just import the dependencies you need that way. I don’t know if step by step is documented anywhere. I used this page to find the dependencies I needed.

https://wiki.jmonkeyengine.org/jme3/maven.html

@dreamwagon : thanks !
Yes, I’m a bit more familiar with Maven than with Gradle. I’ll check it out …

That is a bit more complicated issue yes. I don’t know if you can call them legacy really. And I think it is more to do with distributing them, the license change you are referring to. And commercial support kinda thing. But sure, with OpenJDK you have to worry much less of these since the more liberal license.

1 Like

Its not a wiki page so wans’t me.

The real page for install is here
Redirect Notice.

An even easier way is to just add this to your gradle build,

project(":assets") {
    apply plugin: "java"

    buildDir = rootProject.file("build/assets")

    sourceSets {
        main {
            resources {
                srcDir '.'
                exclude ('**/*.j3odata','**/*.mesh','**/*.skeleton','**/*.mesh.xml','**/*.skeleton.xml','**/*.scene','**/*.material','**/*.obj','**/*.mtl','**/*.3ds','**/*.dae','**/*.blend','**/*.blend*[0-9]','**/*.bin','**/*.gltf')                
            }
        }
    }
}

project.sync {
    from '../path_to/assets'
    into 'assets'
}

I use the SDK for coding gradle projects as well. I create a folder in the resource directory the SDK uses and in that folder I start a standard jme mygame project for asset management.

I create a gradle project in the same folder, using my own forked, fixed, version of bootmonkey. Because the gradle project has those two statements, when ever I reload the gradle project or run the gradle project, it will sync the assets of the mygame project into the gradle project and properly build the jars of the gradle project distribution by excluding everything thats not supposed to be in the build jars, exactly as the SDK does.

Sync is real fast as it only adds or removes new items. This gives access to all the goodies of the SDK and all the goodness of gradle from the same SDK, best of both worlds.

1 Like

thanks, its good for production :slight_smile:

but for development i dont like jar building for assets(that take loong)

To me it depends on the type of development. If I’m using a bunch of already built assets or textures then it’s no big deal to bundle them in a jar because they rarely/never change… and gradle won’t rebuild the jar unless things change.

…but if it’s a project that’s mostly about the assets and all I’m doing is tweaking assets, running, tweaking assets, running… then a directory is better. At least until the assets are done and/or approaching release.

here examples:

  • using XML file for gui in assets - edit often
  • using txt file for something (that might edit often, dialogues? some settings?)
  • using lipsync files(not often but just as example)
  • also having GB of 4k textures increase wait time (try have a lot of it…)

i could give more examples. Like you said “depends on the type of development”. but there are a lot more of situations you didnt write.

Well, most people do “light-weight” games, so i understand its not a problem. But its not everyone.

edit: anyway we will need “cleanup assets a little(make 50% of weight or even less - have trash files)” because already needed “tasks.distZip.zip64 = true” :rofl:
but since JAR is not builded in development, its not important.