ObjToJme classcastexception error

:?  I'm not sure what you are saying here Badmi…  Wouldn't saving and loading as Spatial give you a greater flexability as to what you can save/load?

Models should be loaded the same way regardless of what converter was used. Since all the other converters use Nodes most of the code gets the first child to access the mesh. Using a Node keeps this constint.

If you want to use Spatial all the demos should cast the loaded file into a spatial.

Having a node or a mesh as the top level item really depends on the scene being saved.  I'm not a fan of the convertor adding extra scene levels (like some master node) if the incoming model file already has a root, or is a single mesh.  It really should come in as the artist created it.  That said, the model importers have lots of room for consistency changes, bug fixes, and what not.

I see your concerns, you are probably right.

I didn't want to put this into the issue tracker yet, as I'm not sure it's a bug (I still have LOTS to learn about jME). I noticed that after loading the model and putting it into the TestThirdPersonController example, that the lighting on the model isn't smooth (it's very harsh actually). Is this a problem with the model loader? Or is there someway for me to specify how to smooth the lighting out on the returned Spatial?

Yep, see… it was just me.  :stuck_out_tongue:

Turns out blender does some funny exporting stuff for OBJ files if you don't set things up just right. I got it all fixed though.  :smiley:

one thing to also note is that we don't currently make use of smoothing group information in an obj file.  Not sure if your obj exporters will rely heavily on that when exporting normals or not.

No… I didn't even want to implement smoothing groups in my own obj importer.  :stuck_out_tongue:

I use vertex normals (or don't) to smooth/flatten things when I create the object. I find that gives me more flexibility on the "looks" of a particular model.

Also, does everything in jME need to be triangles? I've noticed that any obj models that aren't strictly built from triangles fail to load.

jME only handles triangles, tri strips and tri fans.  I didn't see anything in the obj format descriptor indicating a distinction…??

I'm not sure what the spec implies on that actually. I just know that Blender definitely outputs non-triangle objects unless you specifically tell it not to. It's really not a big deal though, I was just wondering. I'll be sure to export all my models with only triangles.  :smiley:

I'd like to support it, even if we convert to triangles ourselves.  Perhaps it is based simply on the number of verts specified in a given face line.  We try to handle more than 3 by building additional triangles in a manner similar to triangle strips.  When you export with quads, what happens?  Do you get an error, or are you missing parts of the model?

I get the following error:

java.lang.ArrayIndexOutOfBoundsException: 0
   at com.jmex.model.XMLparser.Converters.ObjToJme.processLine(Unknown Source)
   at com.jmex.model.XMLparser.Converters.ObjToJme.convert(Unknown Source)
   at spaceops.TestThirdPersonController.setupCharacter(TestThirdPersonController.java:175)
   at spaceops.TestThirdPersonController.simpleInitGame(TestThirdPersonController.java:106)
   at com.jme.app.BaseSimpleGame.initGame(Unknown Source)
   at com.jme.app.SimplePassGame.initGame(Unknown Source)
   at com.jme.app.BaseGame.start(Unknown Source)
   at spaceops.TestThirdPersonController.main(TestThirdPersonController.java:95)

Looks like an issue processing lines that have white space.  Added a fix which should make it into cvs later today.