Hi! Waffenwars and I have been working on getting COLLADA data out from 3ds max and into jme but with no luck. Can anyone give us directions on how to get it done?
a. Should we keep on trying to export directly to COLLADA from 3ds max (Please provide some hints to the export settings)
b. Should we convert 3ds to maya and then export using the guide from the JME wiki?
c. Any other suggestion?
Any help will be greatly appreciated!
If you install the COLLADA plugin provided by Feeling Soft, you should have no problems. However, Feeling Softs support of exporters is minimal for 3DS (we had to write our own exporter at work).
I just looked in Waffenwars' exported collada file and saw the following line
<authoring_tool>Feeling ColladaMax v3.00 with FCollada v3.00.</authoring_tool>
and hence it seems that we are already using the plugin you're suggesting. We, however, have a lot of trouble getting it to work with jme. Can anyone give a simple step-by-step instruction on how to export a small model with texture to collada in a way that is compatible with JME?
Is that the latest plugin version available? I vaguely remember our artists mentioning various plugins from feelingsoft had various issues.
Yes, that is the latest version, build 302 from feeling software. I tried following instructions from
another thread but it was for a version with different options, so it didn't work. Textures are not
showing up, and the animation only responds to the first bone in the hierarchy.
Waffenwars
We finally got it to work! I will explain what we needed to do with the animations and waffenwars will post how he put the settings in order to get the textures right.
I basically compared a working COLLADA document with our document and found out that the only difference was that the working document had all animations wrapped in a top level animation called "Animation". By adding a <animation id="Animation"> tag right after <library_animations> and a corresponding end tag at the right place it worked.
Can anyone explain why there has to be a top level animation? Is this due to the ColladaImporter code or the TestColladaLoading code? It would be very nice if it wasn't necessary to manually add the top level animation (and change version from 1.4.1 to 1.4.0) 
Hmmm, no "Animation" is not required… but perhaps a single animation enclosing the others is? For instance, you can probably name that top level animation tag anything and it won't matter: (example from work: <animation id="F01_Human_Female_Base_1hSword_Act_Fidget_1">). The question is, why were your original exports not containing all the sub animations (which I am assuming worked on a single bone) as a single animation?
Let me talk with our tech artist about upgrading from 1.4 to 1.4.1, he shouldn't have a problem with doing it. If not, I'll get 1.4.1 compliant code up in the next update.
Yeah you're right about the naming it is arbitrary as long as we have an animation enclosing the others. I will have waffenwars post on the feeling software forums about why we don't get such an enclosing animation no matter what we do. It would be very nice with the 1.4.1 upgrade. If your artist don't like the idea maybe we can let the old parser just make warning about 1.4.1 instead of 1.4.0 and then try to parse the COLLADA anyway. For most purposes it will probably be backward compatible and if people encounter a case where it isn't then they have been warned
As far as textures goes, all I did was change my Blinn to a Phong shader as I found that's what the collada file was trying to load in. uvw coords and everything is working fine now.
For the people with problems like mine here's a quick fix that's definately not robust in any way but it removes the need for manually editing your colladafiles. It's basically a preprocessor that takes a COLLADA input stream, does the work necessary and then returns a working input stream for use with the JME collada importer
import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.io.InputStream;
public class ColladaPreprocessor {
private static final String lookup1 = "<library_animations>";
private static final String lookup2 = "</library_animations>";
private static final String lookup3 = "version="1.4.1">";
private static final String insert1 = "<animation id="Animation">";
private static final String insert2 = "</animation>";
private static final String replacement = "version="1.4.0">";
/**
* Known issue: The preprocessor does it's work no matter if it's
* necessary or not. If it wasn't necessary then the produced
* COLLADA stream won't work.
* @param colladaStream The stream to be preprocessed.
* @return The preprocessed stream.
*/
public static InputStream preprocess(InputStream colladaStream)
{
try {
byte[] data = new byte[colladaStream.available()];
colladaStream.read(data);
String str = new String(data);
StringBuilder sb = new StringBuilder(str.length()
+insert1.length()+insert2.length()
+(replacement.length()-lookup3.length()));
sb.append(str);
int index1 = sb.indexOf(lookup1);
if (index1>-1)
sb.insert(index1+lookup1.length(), insert1);
int index2 = sb.indexOf(lookup2);
if (index2>-1)
sb.insert(index2, insert2);
int index3 = sb.indexOf(lookup3);
if (index3>-1)
sb.replace(index3, index3+lookup3.length(), replacement);
return new ByteArrayInputStream(sb.toString().getBytes());
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return null;
}
}
I updated the ColladaImporter to still work with "unsupported" versions of Collada (ie. 1.4.1) so it just throws a warning and continues to load, so that part is no longer necessary.
Sounds good!