Why is there a null error when I import a .scene

I’m trying to import a level, which I made in blender 2.69, for more then two weeks now, but I can’t get it to work.

Things I tried:

  • I tried to use blender 2.8, but the ogre exporter isn’t updated in years, so it didn’t work.
  • I tried to use the .blend file, .fbx, .obj and .glb file.
  • I tried the .scene file with the ogre exporter
  • I tried the .mesh file with the ogre exporter, but the level is made of different objects so I have to use the .scene

This error is given:

    Unsupported pass directive: alpha_to_coverage
    Unsupported pass directive: colour_write
    Unsupported pass directive: depth_check
    Unsupported pass directive: depth_func
    Unsupported pass directive: depth_write
    Unsupported pass directive: illumination_stage
    Unsupported pass directive: light_clip_planes
    Unsupported pass directive: light_scissor
    Unsupported pass directive: normalise_normals
    Unsupported pass directive: polygon_mode
    Unsupported pass directive: scene_blend_op
    Unsupported pass directive: shading
    Unsupported pass directive: transparent_sorting
    Cannot locate resource: Models/LevelTest/Cube.033.mesh.xml
    An Exception has occured when trying to load asset LevelTest
    java.lang.NullPointerException
    	at com.jme3.scene.plugins.ogre.SceneMeshLoader.load(SceneMeshLoader.java:15)
    	at com.jme3.scene.plugins.ogre.SceneLoader.parseEntity(SceneLoader.java:304)
    	at com.jme3.scene.plugins.ogre.SceneLoader.startElement(SceneLoader.java:395)
    	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:509)
    	at com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:182)
    	at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:351)
    	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2784)
    	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:602)
    	at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
    	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:505)
    	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:842)
    	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:771)
    	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
    	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
    	at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)
    	at com.jme3.scene.plugins.ogre.SceneLoader.load(SceneLoader.java:537)
    	at com.jme3.asset.DesktopAssetManager.loadLocatedAsset(DesktopAssetManager.java:259)
    	at com.jme3.asset.DesktopAssetManager.loadAsset(DesktopAssetManager.java:373)
    	at com.jme3.asset.DesktopAssetManager.loadModel(DesktopAssetManager.java:416)
    	at com.jme3.gde.core.assets.SpatialAssetDataObject.loadAsset(SpatialAssetDataObject.java:94)
    	at com.jme3.gde.core.assets.SpatialAssetDataObject.loadAsset(SpatialAssetDataObject.java:53)
    	at com.jme3.gde.core.assets.AssetData.loadAsset(AssetData.java:130)
    	at com.jme3.gde.modelimporter.ImportModel.copyModel(ImportModel.java:208)
    	at com.jme3.gde.modelimporter.ImportModel.access$000(ImportModel.java:63)
    	at com.jme3.gde.modelimporter.ImportModel$1.run(ImportModel.java:102)
    	at java.lang.Thread.run(Thread.java:748)

I have no idea how to import the scene!
Btw I’m also using flat shading instead of smooth (in blender), but it doesn’t seem to work in jme3 (I tried it with a single object, so I could import it as .mesh).

Any ideas would be helpful, thank you.

Export it to GLTF and import the GLTF file. GLTF is the recommended route for importing models these days. The others are more of a legacy thing.

1 Like

to solve this in your place i would try export simple cube and see. Probably you have there something that cause issue. (but looking at issue line, it refer to assetKey that is odd)

.obj and .gltf should work for sure.

.gltf is suggested one because its new standard and will be supported long time.

When I try to export as .GLTF it only exports as .glb and it seems like that format is not supported by jme3. When I try to import a .glb it doesn’t give an object, but just a text file and with the normal model importer I can’t even go to the next step after selecting the file.

every GLTF information you will find here:

https://wiki.jmonkeyengine.org/jme3/advanced/blender_gltf.html#jme3/external/blender

to let you know it was working for me on both Blender 2.79(that required older plugin) and Blender 2.8(that is best to export now). And in both i seen switch to choose “gltf” or “glb” formats, so im unsure why you dont see.(in above link see " Export options")

based on wiki .glb should work too(its just compressed format), but myself i was always loading .gltf

Anyway in above link is Every information required to use GLTF. (some of use spent time to list all requirements/tips)

When I try to import a .glb it doesn’t give an object, but just a text file and with the normal model importer I can’t even go to the next step after selecting the file.

edit:

i think you use SDK button import? well you dont even need use it, but maybe this button itself have issues, would need ask @Darkchaos Myself i never use this button in SDK.(because no need)

see below, you just place model(with all textures/etc) in Assets/ folder in game and you can load it like:

“assetManager.loadModel(“Assets/Models/YourModel.gltf”)”

This will give you “spatial”

To also let you know what is spatial. Spatial is Anything scene related, it can be Geometry, Node, etc… you need Cast it to proper class (like people do a lot of java casts)

i will provide you some links too:

https://wiki.jmonkeyengine.org/jme3/beginner/hello_asset.html
https://wiki.jmonkeyengine.org/jme3.html#tutorials-for-beginners
https://wiki.jmonkeyengine.org/jme3.html#documentation-for-intermediate-users
https://wiki.jmonkeyengine.org/jme3.html#documentation-for-advanced-users

Also, you have JMETests project(that you can easly open in SDK) where you got ready to run Tests with visible code. That can help you see your issues.

Anyway since you are new i belive?(i see you joined 2h ago) then i think the best way would be if you would look JME Tests and also read ALL beginners wiki page. Later you can play with own tests and read other wiki pages, and step by step learn how things works.

here is image from SDK how to open Tests project with example tests.

Also to let you know, you dont even need SDK to work with this engine trully. (you can use it just to export models to .j3o if you need)

like wiki say, you can use other IDE too(that dont even have this “import model” buttons)

and well, as i now know you are totally new (i belive), then welcome to JME community :slight_smile:

In blender 2.8 there is a drop down to specify the save type. Click export to gltf and on the left side of the screen will be the drop down.

Also make sure to validate your Gltf model in an online Gltf viewer before importing it into JME.

Here is the link to a few of them:

https://sandbox.babylonjs.com/

https://gltf-viewer.donmccurdy.com/

Thanks guys, it works!
And yes I’m new here, I have experience in Unity, but this is really different. Especcialy importing the models was some pain, but it works now! Thank you all.

Yes, since Unity is more “click everything pattern”(and they rely on their app a lot) here is “code everything pattern”.

Well, you have SDK and you can click some things, but anyway 100% can be done with just coding in any IDE.

JME is trully 50% Java and 50% C, because big libs like OpenGL, jme3-bullet-native, etc are in C. (distributed for MAC/Linux/Windows versions of C libs)

Im not sure if you are Gradle experienced user, but a lot of people here use Gradle for build game code instead of Ant(default in SDK). Well even engine itself is builded in Gradle.

Sorry that I read this so late:
Converting in the SDK SHOULD work, gltf and glb (though I think that glb files needed an accompaning gltf file?), otherwise if the model is non-proprietary, please open an issue at GitHub - jMonkeyEngine/sdk: The jMonkeyEngine3 SDK based on netbeans

Note that importing can be as easy as copying the files into your asset directory and right click them to select “Convert to j3o file”.

I advise to not use @oxplay2’s solution as the j3o format is the only format meant to be loaded at runtime. Not only is gltf slower as it’s json (and might be doing some conversion of coordinate systems, calculating tangents), but also engine related changes (e.g. the material) are lost when you don’t work on a j3o file. Also gltf files mean everyone could copy your models, for j3o the barrier is higher.

Did the model work in an online viewer?

Also regarding your first post:

  • Direct Blend Importing only works with < 2.8
  • obj should work, although it’s not really awesome
  • fbx is kind of hard, as it is proprietary (at least the binary version) and the SDK thus used the route of converting fbx to blend and import that directly, which broke with 2.8 as well (though the sdk comes with a non 2.8 blender)

Did you solve the smooth vs flat shading?

1 Like

I advise to not use @oxplay2’s solution as the j3o format is the only format meant to be loaded at runtime. Not only is gltf slower as it’s json (and might be doing some conversion of coordinate systems, calculating tangents), but also engine related changes (e.g. the material) are lost when you don’t work on a j3o file. Also gltf files mean everyone could copy your models, for j3o the barrier is higher.

Seems like you dont get what i mean.

Well, if you want lost time during development, you can use j3o while develop. Converting each time you change model or play arround some scene.

IMO j3o should be used for PRODUCION or late development ONLY - to save a lot of converting time(and reapply material data time if someone do)

Anyway about your “Also gltf files mean everyone could copy your models, for j3o the barrier is higher.” hehe, everyone can read j3o too, its default JME format :wink: solution for “security” should be different.

Myself to secure format, would do “custom” compress/data type over j3o. But still it would be not enough. Best security is a “LAW” + “custom format based on j3o” :wink:

edit: to even give you example, Skyrim models were already on Internet, did someone did game using them? NO. :wink: Why? its certain why.

You will start your game like 1000000x more during development than you will adjust your model. Why have to wait all the time to load some heavier format? Why is it a big deal just to run the jmec script again when you make an edit? Why wait until production to debug all of your problems?

It’s silly to wait.

There is a big difference between loading the gltf directly in some editor and having to somehow reverse the j3o format so you can load it into an editor. j3o is pretty close to a custom format at that point.

Even your custom data format is not much more secure than .j3o in that light. If your game can load it then so can my code.

Even your custom data format is not much more secure than .j3o in that light. If your game can load it then so can my code.

yes, and this was already told before i remember. There is no way to protect fully.

You will start your game like 1000000x more during development than you will adjust your model. Why have to wait all the time to load some heavier format? Why is it a big deal just to run the jmec script again when you make an edit? Why wait until production to debug all of your problems?

It’s silly to wait.

Depends how you develop. If you load “all models” to just check simple things in game, then yes.

But for example:

  • prepare scene where some “nodes” should be filled with random things “ingame”.
  • you want test this scene a lot of time
  • in your way it would be “export model to GLTF → export to j3o(find and click) / run jmec(well idk if its full auto, if yes its nice) → run Test”
  • in my way i prefer “export model to GLTF → run Test”

Do you want to say my way is “slower testing” in above example?

But if you mean some “automation j3o export after GLTF export” then i agree it would be best

My way would be:
-export it
-run test (which is using gradle and will run jmec if required)

But even if you have to run two command line commands after export… it’s not that big of a deal.

Yes, using the SDK every time would be awful. I don’t even use it the first time.

My way would be:
-export it
-run test (which is using gradle and will run jmec if required)

this is almost same what i suggest.

I see almost no difference on Game(Test) run if “game parse GLTF into Spatial” or “jmec parse GLTF into j3o to load faster ingame”

didnt you agree?

the difference is see:

my is little faster, but yours could “skip already j3o exported(and that dont require update) gltf files”.

both have advantages. in MID and LATE DEVELOPMENT yours is better ofc.(if it check what j3o to update)

It’s a fairly unique development situation where one is editing their models more often than their game code. If someone is in that unique situation then sure, go with the less generally optimal route.

For anyone likely to run their game more often than they edit their models, its optimal to use j3o.

Anyway if you would provide gradle code with JMEC to update j3o(“only ones with changed gltf files”)

it would be best anyway and i would suggest it each time.

BTW. i seen SDK already track changes, but myself i had errors and issues when apply new changes into j3o.

also to show i suggest j3o, i just tell “its not required” is this recent post:

that again show i only tell “its not required to export into j3o” that a lot of new people dont even know.