SDK Released for v3.2

Due to the constant request of multiple users I made v3.2-prealpha-sdk1 available yesterday :confetti_ball: :tada:
This means you can now try the latest engine features like PBR, the new Profiler and many other cool things.

Notes about this Release:
Note that prealpha means that there isn’t even a alpha1 engine version right now, so we just take what is on master at the time of the build (which also means no reliable engine version, however the engine build is always outputted as you start the sdk). This is also why I hope that you will experience many bugs (so we can fix them!). Specifically I expect PBR Materials and Shadernodes to have some bugs since those are new/not much tested as of now. The SDK has support for PBR and as such I guess you can place Lightprobes and such in the Scene Composer already, but bugs may appear.

General Notes:
With this announcement I want to state a few things about the sdk in general though:

Personal Opinon:
I’ll first start with a personal opinion (whining):
In the past, I’ve seen many people complaining about the sdk. They don’t use it because it just sucks.
Now while you are free to have that opinion, there is no way for the SDK to improve.
If you look at the Issues, you’ll see there isn’t much there. Most of those things are one-time problems with ancient versions on ancient computers or design/feature requests.

While I can understand that it’s just more fancy to use IntelliJ with a dark theme while sipping a club mate through you a red straw while maintaining your work-life-balance by playing foosball, I can’t see anything bad with netbeans itself. Sure it’s not fancy, but technically NB, Eclipse and IntelliJ aren’t really far away. For example there is a Gradle Plugin for Netbeans and I use the SDK for all kind of projects. I use it for university projects (they are using jme now ;)) and all.

Sure you have an opinion but I don’t see a reason to hate one IDE or another, you just get used to the workflow. If it’s something apart from the workflow, we’d love to hear from you, because that is the only way we can improve at all. This holds true for the engine itself. For example I just discovered that the android tests weren’t buildable due to some awt dependencies. No one ever reported that.

I know that sometimes waiting for an issue to be fixed might be annoying, I also know that reporting an issue might not be fun, but even only the subject might help us even KNOWING that there is something wrong. This btw increases the release cycle speed. Take the engine as an example: Since there weren’t any reports (positive or negative) the core team just waited a few days/weeks until the next version got released.

It sounds demanding however this is my overall impression at the moment: We need more feedback, more community. It’s Open Source, just dare to get your feet wet, technically you can’t do anything wrong, we’ll help you to help. That is how I started, for example: I had a look at some engine issues which were pretty easy to fix and I submitted PRs for them.

If you for example want to learn about that process for non critical things, take a look at the javadoc warnings appearing during build. Most of the time only a parameter name has been changed, the parameter has been removed or it simply misses two words (e.g. @param spat, you add the spatial to process). Missing @Override's are another common thing, typos, etc.
These are things were you can learn how to do it without much effort (e.g. trying to understand the problem and all), and we’d be happy to see you on board. We’re also open to bigger changes and actual bugfixes, if you feel ready, just make sure to format your code properly (SDK: Source->Format) and have a descriptive PR.

If you are still reading here then you might ask yourself the same question as I do now: Why the hell did I write so much about something so obvious, I don’t know :see_no_evil:

Building the SDK on your own:
See here

Why don’t the updates work:
I’ve written it multiple times and considering the amount of text I already put into my opinion I am keeping this short:

We used to have an own server/webspace I consisted of a maven repository and the netbeans/sdk repository where plugins and updates were stored. I think this server was a sponsorship deal arranged by a monkey. Anyhow as it happens mostly for OSS: People disappeared, got distracted by own projects, got kidnapped by Arnold or killed by HAL-9000.

This lead to us being unable to publish several maven artifacts (jme3-jbullet , jme3-testdata, etc), because for jCenter they might be ToS violating (Test Data has no code or javadoc, it’s all resources).
Apart from that, SDK plugins and updates stopped working.

To prevent such a kind of issue again, we are actually trying to reduce complexity by relying on other services (instead of our jenkins server we use travis, instead of our own maven there is jCenter), but we still miss that part for the SDK:

Technically we only need some Webspace with FTP or SSH (SCP) access. However this should be some Open-Source Plan (no arranged manual sponsorship and such) possibly accessible using Github Team Sign On, so that unless the whole team is kidnapped, there is always the chance to recover.

We’d need something like a cloud storage, web space thing, some CDN, AWS, I don’t know what :stuck_out_tongue:
We do not want to setup a server or something like this though, just FTP and go. However we need Directory Listings to be enabled.

Feel free to suggest something to us as long as it’s a publicly available deal for Open Source Projects (Since everything else adds inreliability and uncertainity). I tried searching myself however a search only brings up open source cloud software instead of cloud for open source software :smiley:

I even had a look at github:ripienaar/free-for-dev however I don’t know if I’ve overlooked something.


Cool. Some SDK integration for the cool new engine tools like the debugger and skeleton debugger etc would be nice as well.

The most reason that stoped me from using SDK is this:

We really need some cloud storage!

Really, too.
Last week I was teaching a student use jme3 in Android, I simplely write an exmaple to load a .blend model, then I found that the jme3-blender was depends on jme3-desktop, which make the project not buildable.
What I did is remove the jme3-blender dependency and use jME SDK to convert the blender model to j3o. I told my student “Always load a j3o model in an Android app, it’s much faster!”


And desktop, too. We always recommend using j3o in your applications… which is why the blender importer dependency is not included in applications by default.

1 Like

I appreciate your effort to make jme 3.2 available with the SDK :smile: I’ll give it a try asap.

Thanks for the update!
Probably not gonna try it until later though, unless someone knows a way to transfer the configs from the old SDK to a new install.
Also, any plans on implementing the SDK updating itself?

If you read the correct section in the post then yes :wink:

And define settings? Projects should stay so it should be only some minor stuff stored in a config subfolder

1 Like

Awesome and thanks for the update :).

@ reporting issues… I only use the SDK and well… i don’t have much bugs. The only thing what can happen if you move the scene composer to a new window and back it crashes and says something like “Attempt to put onto different graphics device”

thank you and keep up with this great work.

Maybe you could send an email to the google firebase team? They may offer some services for free for an open source project.


I checked and they already do: Firebase Pricing

There’s a 10 GB/month data cap, but as suggested, contacting them might raise the bar…

It’s even 1GB/month for Storage. I’ll talk with the team and google and see what happens :slight_smile:

Our Spark and Flame plans can be used by any type of individual or organization, including nonprofits, schools, and open-source projects. Since these plans already include generous quotas, we don’t offer any special discounts or plans for open-source, nonprofit, or educational projects

This is a bit bad news, since I planned on hosting the installers there as well…
With 500MiB each that is 20 downloads per month. I don’t know if they take us offline then or just cap the bandwidth?

Doing the maths: 3.1-stable was released 34 days ago and has these download stats: => 1021 => 54
jmonkeyplatform-macosx.tgz => 243
jmonkeyplatform-windows-x64.exe => 3255
jmonkeyplatform-windows-x86.exe => 603 => 599

Now generously assuming 500MiB per file and a pretending a month would have 30 days:
5775 Downloads/Month → 2.887,5 GB/Month.

Holy Moly Monkeys, we produced nearly 3TB Traffic for Github only for stable and only last month. No wonder some people get their downloads refused :joy_cat:


I can write a bit of javascript to auto-upload a file to google drive. Google offers this functionality for websites.

I dont know if maybe we could even inject that into a post on this forum…? Iv never tried. But it might be something to look into. It solves a lotof the issues indirectly… bandwidth, storage space, alternative downloads… im sure there are a few other mainstream clouds that offer it too, such as onedrive and dropbox.

Edit: or maybe even use one of the github pages since its just javascript. Anyway, its all i have for ideas im afraid. Other than that id need an actual server.


@Darkchaos Nice work, thank you. :wink:

Unfortunately there is one Issue with all of those ideas: Traffic.

If you use the free google drive version, I know that some links get disabled for causing too much traffic.
This also effect the forum. The Filesize Limit is 10MiB and I guess serving files isn’t part of the deal.
Another problem with dropbox and the like is that they don’t provide the Directory Listings or File Structures which netbeans needs to detect modules.

Github Pages wasn’t what I thought of but maybe github’s rawusercontent. The Problem with this is that git is neither for storing large binary data (github limits the size to 100MiB, which would work for our modules though) nor would it be long lasting since the clone time will increase from release to release.

Git LFS however is basically storing a link to somewhere else. That solves that problem however I don’t know if we don’t need something like dropbox again then. Plus it would be to investigate if rawusercontent supports this?

Now actually thinking about it, some small webspace seems like the best option but then we’re prone to the same problem again. There have to be OSS which store there downloads/updates somewhere? I can’t believe there is no real service for that, actually. Or some webspace for OSS, mhh.

Well - one thing at a time. The “save to cloud” (google/onedrive/dropbox/etc) buttons remote-upload a file (in this case the SDK) to your own account. So if I clicked it - it would be in mine - if you clicked it - it would be in yours. There would would be no single end-point. I’m not sure where you read the file limits - but as far as I am aware there are no limits other than your own storage limit. This only solves one of the many issues you have - which is allowing the user to download from an alternative mirror.

1 Like

AH, got it! That’s what you meant.
You even made a tutorial about that actually^^

And I did not read about that limit but I was sometimes given a link which was unaccessible due to exceeded traffic. This however doesn’t matter for the users own storage actually.

Great work! Could you include the Netbeans platform version as well? I always find those release notes worth of reading.

1 Like

It is 8.2 since roughly beta1 I think. However note that there is an android problem with 8.2, which I don’t know how to properly solve.


Maybe BitTorrent could be a solution for those big files?

Yes and no.

  1. You also need a server to seed or else people are unable to download
  2. It’s more complicated and we have people which are unable to add the file to their google drive, we would be explaining how to use torrent for ages
  3. The SDK can’t use that for updates

@jayfella Maybe it’s enough if I add a link to a proper post for each release?

1 Like