We need help maintaining the SDK

erlend_sh · September 5, 2015, 1:35pm

For a while now, @normen has been taking a backseat in the development of jMonkeyEngine. This is unlikely to change. With the 3.1 alpha release available for testing, bug reports are popping up as expected. What we didn’t quite expect is how time consuming certain SDK issues are, and we’ve realised we could really use a helping hand with these issues.

If you know your way around the NetBeans Platform, or can catch on quick, please have a look at the existing issues and try lend a hand.

Don’t hesitate to ask us for help!

As for the future of the SDK, we can go deeper into that discussion once v3.1 goes stable.

Dokthar · September 5, 2015, 2:32pm

I’im !
I hope i’ll have time to look into this.

bloodwalker · September 5, 2015, 3:02pm

Once I am done with dominoes I will also take a look at the SDK. It’s really useful to me and many of us here. I’m in

Darkchaos · September 5, 2015, 5:30pm

I am quite busy but I tried to look into the .blend-Issue and found out something weird:
When I open the file with my 2.75a Mac Blender and save it, the issue is gone, when I use the OPs file, I get the same issue.

Another thing:

[catch] at com.jme3.gde.core.assets.SpatialAssetDataObject.loadAsset(SpatialAssetDataObject.java:95)
	at com.jme3.gde.core.assets.SpatialAssetDataObject.loadAsset(SpatialAssetDataObject.java:54)
	at com.jme3.gde.core.assets.AssetData.loadAsset(AssetData.java:130)
	at com.jme3.gde.modelimporter.ModelImporterVisualPanel3.loadModel(ModelImporterVisualPanel3.java:92)

The catch in SpatialAssetDataObject prevents ModelImporterVisualPanel3.java from printing helpful Information. Instead it uses Exceptions (openIDE Class).printStackTrace() which is only seen on stdout.

Could it be that the SDK Log is filtering for “com.jme” classes and so the “SEVERE [org.openide.util.Exceptions]” is discarded?

PS: Is this thread even the right place to discuss this or should this rather be on Github?

Edit: Are you the same @slyh as on GitHub?

I could track the issue down to uv-coordinates: We have 88 UV-Coordinates in the UVMap and the broken Blender-File defines 92 whereas my “fixed” one also only sees 88 UV-Cordinates.

Maybe your Blender produced that faulty file and it’s maybe already hot fixed in the version I just downloaded?
If not, try to only use quad-UVs, maybe that helps.

BROKEN:
userUVGroup: UVTex; loopStart: 0, totLoop: 3, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 3, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 7, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 11, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 15, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 19, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 23, totLoop: 3, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 26, totLoop: 3, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 29, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 33, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 37, totLoop: 3, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 40, totLoop: 3, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 43, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 47, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 51, totLoop: 3, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 54, totLoop: 3, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 57, totLoop: 3, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 60, totLoop: 3, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 63, totLoop: 3, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 66, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 70, totLoop: 3, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 73, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 77, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 81, totLoop: 3, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 84, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 88, totLoop: 4, entry.getValue().getLength(): 88

The Working one:

userUVGroup: UVTex; loopStart: 0, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 4, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 8, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 12, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 16, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 20, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 24, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 28, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 32, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 36, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 40, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 44, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 48, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 52, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 56, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 60, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 64, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 68, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 72, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 76, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 80, totLoop: 4, entry.getValue().getLength(): 88
userUVGroup: UVTex; loopStart: 84, totLoop: 4, entry.getValue().getLength(): 88

Maybe someone can play around with that, it would be interesting to see if the broken blend file is correctly uv mapped if we simply discard the last faulty uv’s. Since the File came without a texture I can’t tell

Edit2: I just checked the broken blender file again: it’s all 2 faces per window and each having a simple quad mapped to it. Since it’s 11 Windows the 88 UV’s are correct. Maybe the OP really had/has a broken blender version?

Try to redownload blender and see if that fixes it

pspeed · September 5, 2015, 6:36pm

Note: it occurs to me that discussions about specific issues might be better served in their own topics.

I think the real point of this thread is to try to organize ongoing SDK support going forward so that it doesn’t atrophy and die. Specific issues are important but they kind of derail the conversation here.

Edit: And note, I already have a way better ‘warm’ feeling as to the longevity of the SDK than I did before this thread was created. So thanks for those who are stepping up to this.

slyh · September 5, 2015, 10:40pm

I’ll reply here for now. Maybe we should move this topic to Github.

First of all, yes, I’m “slyh” here and “slyh80” on Github. And I’m absolutely baffled by this problem.

I just now downloaded Blender 2.75a (Windows 64bit) again as portable ZIP file. After saving our test file again it still crashes in jMonkey. I even deleted all previously installed versions in C:\Program Files and all configurations in C:\Users\MyUser\AppData\Roaming and tried again. No success either. I also tried out the 32 Bit version.

For my minimal test case the problem goes away when I either remove the UVMap from the windows, or when I add an UVMap to the door. This could be an indication that we are dealing with a Blender bug rather than of a jMonkey bug. At least on my system, I guess?!
Simply saving the file again without making changes or only after moving stuff around in the scene will not fix the problem on my system.

From your post it seems that you assume the crash occurring when the UVMap of the windows are parsed. For me it looks as if the crash occurs when Door.Corpus.Mesh is parsed. It has more than 88 faces. It does NOT have an explicitly defined UVMap, though. Maybe Blender still creates one, which is faulty?! Or maybe there is a bug in the Blender importer, where the importer tries to use the UVMap of a previously read object if the currently processed object does not have one? Or some random other object in the scene if there is no UVMap defined? Just some guesses.

Apart from redownloading, can I support you in any other way during your investigation?

Darkchaos · September 5, 2015, 10:58pm

I don’t have an GitHub account atm that’s why I posted here.
JME shouldn’t crash though (It doesn’t do here, it simply doesn’t display an error message but stays).

It’s really crazy that my Mac Version works
Over here I have the following: The Windows have an UVMap, named UVTex and the Door doesn’t have one.

It definitely is that UVMap (or rather the information on how to read the Vector2f’s as UV Coords) because that output is made by sout() directly before the exception.

Try if that blend imports for you: building-crash-test.blend - Google Drive (it’s just my reopened one).

We should move that to another thread though, but in that case I can’t help you much further, as I don’t know if the buffer is wrong or the loopInformation (though I guess it’s the latter as you won’t use triangles for windows).

Try your complex files and make sure they all have uvmaps, in that case it could be BlenderImporter generating faulty UVMaps, though I don’t know why and how it should.

btw: if you need a workaround use the blender2ogre exporter and then the ogre importer.

pspeed · September 6, 2015, 12:06am

No. Discussions should happen here. There is already too much missed stuff on github.

slyh · September 6, 2015, 9:46am

For me it definitely crashes while loading the Door mesh.

Your blend file loads fine on my machine.

As it seems more of a Blender bug right now I downloaded the current test build of Blender 2.76 from http://download.blender.org/release/Blender2.76/

I resaved the broken testcase file and it now loads perfectly in jMonkey. The full scene for which the problem originally occurred now works, too. So maybe we really had a Blender bug here.

There is still another issue with scrambled UV maps in one of my scene though, which I mentioned Blender Loader crashes for files created with Blender 2.75 · Issue #322 · jMonkeyEngine/jmonkeyengine · GitHub So maybe it’s a jMonkey bug after alll. ;-))

I’ll update the github issue with this new information and link to this discussion.
Let’s see what happens when the final version of Blender 2.76 is released…

Darkchaos · September 6, 2015, 12:10pm

Then it’s somehow “solved” fortunately, it would be interesting to check blender’s git if they did know the bug or if it happens randomly, because on Mac it works, on Windows it doesn’t.

If you feel bored, you can try 2.75a in a Linux VM and see if it works there ^^

As for the other bug, you talk about #325? It’s interesting because at least in 3.0 it worked because the error you describe would destroy most uv-maps. Did you actually encounter that problem or do you only suspect it to be there because of the way you read the code?
Maybe JME has the same UV System as Blender and flips the UV’s in the Shader?
I might be able to look into that next weekend.

Btw, if you want to try to code/modify on your own, set up a little debug environment, that is:
a) Have a git repo from github (git checkout LINK-TO-REPO) and update it daily (git pull)
b) Build jme+jmp (SDK) by calling ./gradlew.bat build
c) run bin/netbeans (.exe) and compile the JMonkeySDK from there and run it
d) Use the SDK

That way you can see in the netbeans log if and why the SDK crashed (or infact exceptions are caught so the SDK might not crash)

erlend_sh · September 11, 2015, 2:32pm

If anyone starts working on one of the listed problems in issue#329, please create a new issue/pr where you link back to #329, so that we can keep track of who’s doing what.

Momoko_Fan · February 22, 2016, 10:18pm

Since there hasn’t been much activity in regards to maintaining the SDK, it will no longer be included as part of releases. The reasoning being that having an engine-only release is preferable to releasing a broken SDK. There are several showstopper issues as well as lack of a primary maintainer means its pretty difficult to keep it up to date.

BigBob · February 22, 2016, 10:39pm

That sounds terrible . I’m a huge fan of the SDK and am currently using the JME 3.1 SDK.

It’s not broken but there are issues. The many tools in the SDK are extremely useful especially the ability to create JME specific objects so easily like materials and empty scenes.

Its tough to imagine actually having to handwrite the locations of objects in scenes and add proper data.

There don’t seem to be any huge breaking issues though it is frustrating to import an old project.

Unless the tools can be replicated like a scene composer, material editor, etc. It’s going to be tougher to use.

DannyJo · February 22, 2016, 10:49pm

I don’t think the SDK is going away, it’s just being released separately using jme core libraries as dependencies. This way SDK development can be slower than the actual framework development. However someone still needs to take enough interest in the SDK to do some work on it I suppose.

It might just be that in long run the SDK will lag behind the features of the framework. Another option is to eventually replace the features of the SDK with smaller isolated tools for conversion and scene building which are easier to maintain.

Darkchaos · February 22, 2016, 11:34pm

Well personally I think it’s sad to drop the support, especially since there was huge effort being put into the SDK (ShaderNodes, Darkmonkey, Terrain-Overhaul). It’s also what differs JME from pure graphics libs and makes us more artist friendly and complete.

On the other hand, JME is still programmer-centered, so personally I only use the j3o Converter in the SDK (I use the whole SDK, but that’s the only thing I’d be missing with other IDEs).

I think seperating the SDK and JME leaves us with thousands of posts like when there is a change in the Material file and the MaterialEditor refuses to load. On the other hand, having faster release cycles on the framework is good

No matter what happens with the SDK in the long run, I am happy to contribute by fixing small issues (just like the two PR’s I did to the sdk this week), however I can’t actively maintain the sdk, neither time wise nor knowledge wise.

Btw: It would be good to have a sdk tag in github.
And more Issues. Report everything you find

delt0r · February 22, 2016, 11:51pm

The SDK is great. However i think dropping support if you don’t have the people working on it is the best idea. You can’t make an omelet when you don’t have the eggs.

I am just starting a game dev company. I would love to say that i can spend a day a week on the SDK and well i would be using it. But I really can’t commit to that. Also i run pretty much only linux here and won’t have windows setup for a few months.

Also i went over a huge chunk of the source the other day. It is really well written, commented about right and you guys really stick to your style guides. It is a well done project.

For me the engine is more important than the SDK. But the SDK is boss.

pspeed · February 23, 2016, 1:48am

Yeah, I mean all of the core devs would like to keep the SDK… but none of us enough to drop a whole area of expertise just to pick up a new one. Because that’s what it would take since the community also hasn’t provided any resources to fill the gap.

You’ll probably see us spin out some separate tools for the common little things (like model import, etc.)… it will end up being more like what libgdx with lots of job-specific tools.

iamcreasy · February 23, 2016, 6:26am

Does it mean the Material Editor by @nehon won’t be maintained anymore as well?

nehon · February 23, 2016, 7:00am

I’planning to extract the material/shadernode editor in a stand alone app.
It will probably be a swing app, because I also intend to keep a fair share of the code.

I’m a bit sad too that we “drop” the SDK. I’ve put a lot of effort in it. But we don’t really drop it, we intent to reinvent it in a way that makes it easier to contribute to.
Netbeans API is very complicated to get into, and it frightened a lot of contributors along the road.

Aslo, we’ve been advise numerous times to separate the engine tools from the dev IDE, and that’s what we intend to do. So you’ll be able to use eclipse, intellij, netbean or whatever IDE suits you, and use the engine tools separateley (I know some of you already do that).

Lastly, We want to release faster… IMO that’s the best decision in this regard, the SDK postponed releases numerous times.The tooling will be complient up to a certain version of the engine, and the engine will live ny itself. There might be some lag… but hopefully not that much. also know that we put a particular effort in keeping backward compatibility with j3o files, so there won’t be data loss over time … as much as mossible at least

delt0r · February 23, 2016, 8:06am

Yea I went through the nb stuff today… Yuck. Not as in SDK part. just as in the plugin part. Not my cup of tea.

What makes or breaks this for me, is nice pipelines… Good external tools are fine. I can set up ant tasks etc. and update all assets in a single click. So my art guy (My brother) can get fast feedback on what things look like in game. How the animations look and stuff like that.