Do you mean MAYA 8.5 or MAYA 2008 generate collada files that works with JME?
Also I notice 3Ds max 9.0 has (FBX / DAE) exporter. But after export to (.dae) file model don't show up in JME.
http://www.oniva.com/upload/1356/exp.jpg
Should I get 3Ds max 2008 inorder to export collada file works with JME?
http://www.oniva.com/upload/1356/col4.jpg
P.S. Using feelingsoftware's ColladaMax export, model loads up in JME, but animation not working.
renanse said:
and you'll notice that we use auto-generated collada schema classes.
How did you generate them? I'm guessing its based on the Collada grammer
While the grammar may be auto-generated, my personal experience is that a hand-coded parser will be more robust and work better.
And, even though the grammar may be auto-generated, the code has things like this:
// Another bit of a hack that should be improved:
// to put the float arrays into the BoneTransform,
// we need to know what angle it is changing,
// I see know way to determine other than looking
// at the source name.
if (animation.getsamplerAt(j).getinputAt(i)
.getsource().toString().contains(
"Rotate-X-")) {
rotx = (float[]) object;
The right way to do it is to look at the channel element in the animation. The channel element binds the sampler to the target, using the target node name and transform parameter. The transform parameters are not defined in the schema, but are defined in the library_visual_scene per node (such as a translate or rotate element).
The benefit is that you could, if you wanted, animate something like the transparency of a material. I don't know of any exporter that currently generates that kind of animation, but I haven't pushed them all very hard.
renanse said:
Really the important thing to note is that the importer only deals with a certain subset of the available Collada schema.
That was my intention. I didn't mean to say that jME's collada support is bad or something, but I think people should be informed that there are problems.
Just saying that jME loads collada leads most people to think that the entire feature set is supported. Of course that's a rather unreasonable assumption if you know the sheer enormity of that spec, but most people wouldn't know that.
Actually, when I heard "COLLADA implemented" I didn't think all of it was implemented, but I would assume that scenes from Maya and Max, exported with the native COLLADA exporters, and perhaps the Feeling exporters, would work. Like with the C4 engine, for example; it has COLLADA support and makes sure to deal with whatever changes come up with each new release. A working art path is the most important part of any engine, IMO.
It depends mainly on your abilities and aims.
It seems clear that the COLLADA specs are not fully supported by developers (commercial and open source). We can discuss if it is a fault of the format spec; if it is not open to support subsets only; or if it is a poor exporters/importers support, unable to extract the informations from a certain area of the file.
But the point is that if you don't want to play a little with the code and try to rearrange it to your needs maybe you do need another engine; or another exporter/importer.
For example, I decided to go on with the MD5 Reader maintenance when I saw that ChaosDeathFish abandoned it, because I need that loader for my game.
If you need full COLLADA support maybe you could rewrite/modify COLLADA jME code. Or arrange some exporter script to suit your needs. Another example: in the case of kman's Cal3D loader I modified the Blender exporter to make it work correctly.
About documentation I am agree with hevee. A page with the COLLADA features currently supported by jME could be really usefull.
I agree, for example, ogre3d (open source engine) has exporters for most popular modeling tools to export in its .mesh format. If jME had a simple and powerful XML model format it will be much easier to write a working exporter for those modeling tools.
But if you don't like Feeling, what's wrong with the plain DAE exporter that comes with Max? (Or, for earlier versions, with the FBX toolkit for Max?)
If I send you $200, will you commit to supporting COLLADA, and provide technical support the way Eric does with C4? I already own that engine, and a number of others – I'm a collector of engines, because I like picking them apart and figuring out how they work. I get enough of building my own at work…
Another question: is the NCSoft work totally separate from jME, or are you using jME for NCSoft? If it's separate, then did you choose the NCSoft flavor of COLLADA just because it happened to be available?
Btw: congratulations on the move! I did the same kind of move 12 years ago. Apart from the obvious differences, there are a bunch of little things that might trip you up, like the fact they add sales tax to the price listed once you get to the cash register, or the fact that US cell phone plans you pay for incoming and outgoing calls (and the caller has no idea whether your phone number is a cell or regular phone). And the fact that you won't have any credit history for the first year…
which "plain" exporter is that? artists might have hidden that one from me due to lacking in features, but i havent heard about it.
before collada entered mainstream we used the filmbox(fbx) sdk to create a converter from exported fbx files to our own format for import…fbx was supported by lots of modelling programs, but sucked due to being a pretty closed format, needing the native toolkit for conversions…
if you convince 50 people or so to pay me $200 a month i'd be happy to work on jME full time! 
thanks for the info for my upcoming move 
it's a bit scary, but i'm sure the new experiences will do me good s
which "plain" exporter is that? artists might have hidden that one from me due to lacking in features, but i havent heard about it
If you have the FBX exporter for Max, there is an exporter option called "Autodesk (*.FBX, *.DAE)" If you select that format during export, and give your file a name ending in ".dae," then the exporter will write a COLLADA file, not a FilmBox file. So far, I'm not seeing anything bad about the output from that exporter, but I haven't pushed it very hard.
are you using 3Ds max 2008?
I tried 3Ds max 9.0 export (.FBX / .dae) JME is not loading the model and nothing show up
I am not saying the "plain" .DAE exporter works with the JME converter – I'm saying that the COLLADA exported by the "plain" .DAE exporter is well formed, and I don't think JME should support only their custom script – there is no reason (other than time) to not support the plain Max .DAE exporter.
As i suppose you understand, our goal has never been to only support our custom exporter. these are things done on ncsoft time which were nicely agreed upon to commit back to jme(like tons of other things). some things commited back might not go all the way for the general community but work as a starting point for extensions and fixes(we hacked that importer at jadestone and got things working perfectly with the feelingsoft exporter, something we might be able to get commited back).
creating a better colladaimporter(or a general xml format and instead a collada->jme-xml converter) is something that will surely be prioritized when 2.0 is up, if noone of the jme users beats us to it…
jwatte said:
I am not saying the "plain" .DAE exporter works with the JME converter -- I'm saying that the COLLADA exported by the "plain" .DAE exporter is well formed, and I don't think JME should support only their custom script -- there is no reason (other than time) to not support the plain Max .DAE exporter.
What do you mean by "custom script" and "well formed"? Collada allows you to do any one thing about ten different ways... Last year we worked hard to use the Feelingsoft exporter (as Max did not have a collada exporter at that time.) Unfortunately there were so many bugs and contacting Feelingsoft directly for fixes resulted in nothing but negative remarks from them that we ended up being compelled to roll our own. Still, we also export "well formed" Collada XML. So all we're talking about here is supporting the other 9 ways Collada has for doing things.
Actually, I think the FBX/DAE exporter was available last year, too – the only problem is that it's kind of hidden, because it's snuck in as part of the FBX toolkit.
I have to disagree that the current code isn't a hack. The current code looks for specific sub-strings in element ids to identify animation channels. That can't possibly work with other than a few select exporters, and in that case, if you changed how those exporters generated their element Ids, it would still break. There is one, well-defined, way to get animation target data; it's by looking at the <channel> element. If you parse a COLLADA document top down, there actually aren't a whole lot of ways that you can express things from a logical point of view – the difference comes in how the different exporters put together the different pieces. If you have a robust understanding of those pieces, then those differences "shouldn't" matter.
The two big amorphous parts of the standard are how geometry is expressed (could be polygons, or polylist, or triangles), and how effects are expressed (a mess of key/value resolution). But, surprisingly, animation is fairly well defined, which is why I'm a little disappointed that it doesn't work right in the current converter.
Now, I agree that these are my opinions, and others may have other opinions. Please don't think I'm trying to get negative on any one person; I'm just expressing the reactions I have when reading the COLLADA code and comparing to some reference data and the specification.
I appreciate the point of view and even the schooling, but rather than just talking about what you see as wrong in the code, it would be even more useful to actually provide patches. :) It's one thing to talk about knowledge and another to be helpful and put it into practice.
You see, I nourish this secret hope that I can find a game engine where the art path actually works. Finding that is the goal of my collection, if you will. The two that come closest are C4 engine, and lately Ogre3D with the OgreMax exporter. C4, however, has a number of limitations come mostly from it being a work by one guy, spreading himself too thin, and Ogre3D isn't a game engine, it's a renderer.
When there are small things I can easily fix, I do provide patches and code. When it's bigger things, I have to gauge the interest value of actually diving into it, versus the cost in work. The COLLADA code seems extra annoying to fix, because it combines machine-generated schema code with the animation/skin set-up in jME, neither of which I've yet to find enlightenment through.
jwatte said:
When it's bigger things, I have to gauge the interest value of actually diving into it, versus the cost in work
join the club! 8)
If you are looking for the perfect game engine you'll never stop searching. In my opinion I'd rather settle to a project that has potential and a good community and help make it the best engine than to look for something that doesn't exist.
before i read this post, i thought collada is the best for model loading into jme. but now, all these problems bring me back to the old question,
whats the best model format to use?