ASE exporter doesn't read entire node tree?

I have a simple ASE file (insofaras any ASE file is simple :slight_smile: with two items in it. However, when I use the AseToJme converter to convert it, only one of the things in the file get converted and loaded. At least, that's how I interpret the behavior I'm getting.



I call AseToJme using two paths: path/to/file.ase path/to/file.jme  (same directory; also contains textures)

The converter doesn't complain about not being able to find texture names, which I take as a good sign. (It did before I fixed the ASE file).

Then I load it as such:


            java.io.InputStream str = new java.io.FileInputStream(
                  "path/to/file.jme");
            BinaryImporter bi = new BinaryImporter();
            Node cld = (Node)bi.load(str);
            str.close();
            cld.setLocalTranslation(0, -2, -25);
            // There are no materials on the default imported model
            rootNode.attachChild(cld);
            rootNode.updateRenderState();



From what I understand, this should load the entire scene graph subset from the jme file, but I only get one of the two things in the file.

Secondly, the textures aren't actually applied to this object. That surprises me, as the converter complained about not finding the textures, until I removed the paths to the textures, and put in just the plain names in the ASE file. The textures live in the same directory as the .jme file.

Are these known problems? Is there some way I can get this to work right? Any help appreciated.

The problem with AseToJme not dealing with multiple objects turned out to be a bug in AseToJme.

Here is a proposed patch. This patch also fixes the clamping of texture coordinates so it wraps propely.



However, the AseToJme converter isn't out of the woods, yet. First, it doesn't preserve the normals that are included in the ASE file; instead if calculates new normals. Second, it appears to apply all materials only to the root node, which means that the last material wins, and gets applied to all geometry, so it doesn't preserve different textures. Third, it doesn't do animations at all. Fourth, it reads through the file in an n-squared fashion, starting over from the beginning each time it wants to get a material or object.



Is there an actual robust art path to go from 3ds Max to jME for static geometry? For skeletal animated geometry?




Index: AseToJme.java
===================================================================
RCS file: /cvs/jme/src/com/jmex/model/converters/AseToJme.java,v
retrieving revision 1.2
diff -d -u -r1.2 AseToJme.java
--- AseToJme.java   20 Aug 2007 10:28:40 -0000   1.2
+++ AseToJme.java   14 Dec 2007 19:52:58 -0000
@@ -228,7 +228,6 @@
          */
         private void parseFile() {
             ASEMaterialInfo textureInfo = new ASEMaterialInfo();
-            ASEObject mesh = new ASEObject("ASEMesh");
 
             numOfObjects = getObjectCount();
             numOfMaterials = getMaterialCount();
@@ -243,6 +242,7 @@
             }
 
             for (int i = 0; i < numOfObjects; i++) {
+                ASEObject mesh = new ASEObject("ASEMesh");
                 mesh.materialID = -1;
                 moveToObject(i + 1);
                 readObjectInfo(mesh, i + 1);
@@ -352,13 +352,14 @@
                             .getRenderer()
                             .createTextureState();
                     ts.setEnabled(true);
-                       
+
                     Texture t=new Texture();
                     t.setImageLocation("file:/"+filename);
                     t.setTextureKey(new TextureKey(fileURL, true, TextureManager.COMPRESS_BY_DEFAULT ? Image.GUESS_FORMAT : Image.GUESS_FORMAT_NO_S3TC));
-                    t.setAnisoLevel(0.0f);
+                    t.setAnisoLevel(AseToJme.DEFAULT_ANISOTROPIC);
                     t.setMipmapState(Texture.MM_LINEAR_LINEAR);
                     t.setFilter(Texture.FM_LINEAR);
+                    t.setWrap(Texture.WM_WRAP_S_WRAP_T);
                     ts.setTexture(t);
                     mynode.setRenderState(ts);
                 }
@@ -839,4 +840,5 @@
             }
         };
     }
+    public static float DEFAULT_ANISOTROPIC = 0.0f;
 }


ASE does not seem to be used very often in jME. Now I know the reason :stuck_out_tongue:



I'm using .3ds for static stuff - but I think it does not do animationsā€¦ collada is used by the professional people, I thinkā€¦

We use collada for both.

Wait, I though Collada was to bloated so that it has many features not implemented, specially animationsā€¦ Right?, right? riiiiiiiight?  :evil:



So, if Collada is good for both animations AND static, that would be good to advertise!  :wink:

COLLADA only supports matrix animation, as far as I can tell. The problem with that is that interpolating matrices will deflate the mesh, equivalently to vertex animation (MD2 style). It's also really hard to do a good job of blending animations when they are in matrix format. PRS control data is teh w1n for animation!

Perhaps the COLLADA importer decomposes the matrices to PRS?



These are the warnings I'm getting (and many more!)


WARNING: X not yet supported for animation source.
Dec 14, 2007 3:00:43 PM com.jmex.model.collada.ColladaImporter processSource
WARNING: X not yet supported for animation source.
Dec 14, 2007 3:00:43 PM com.jmex.model.collada.ColladaImporter processSource
WARNING: X not yet supported for animation source.
Dec 14, 2007 3:00:43 PM com.jmex.model.collada.ColladaImporter processAnimation
WARNING: Animation source invalid: Base-translate-animation-outputX
Dec 14, 2007 3:00:43 PM com.jmex.model.collada.ColladaImporter processSource
WARNING: Y not yet supported for animation source.



The code actually seems to be looking for a specific set of text within some element names, which is totally wrong AFAICT. The COLLADA schema actually allows you to figure out what's being animated, by what interpolator data. It's a little annoying, because it has about three levels of indirection more than you would want, but that's because you can animate pretty much anything (such as, say, the opacity of a texture) in COLLADA.