The background is this:
I imported a half-finished model into Blender (now I plan to continue with Blender exclusively). I exported it as 3DS, OBJ/MTL and as Collada. I was able to import all three formats into jME and combine them with collision detection successfully. Only, OBJ and 3DS didn't show transparancy, so I decided I'd stick with Collada 1.4. (And the textures are missing,but this is lower priority now.)
Everything was fine until I continued editing the file with Blender. I created some cubes and transformed and positioned them, and copied and moved existing objects around. In Blender it all looks normal, and exported as 3DS it also works normal in jME.
The Collada file suddenly shows serious problems in jME. All original objects I left untouched in Blender (or which I only aligned with the grid) show as expected. All the objects I modified or created in Blender, however, are tilted, and their scale in jME is shown far different from what they actually are.
A ramp is now a small floating tilted box. One floor turned into a big cube. Railings are too long and lie criss-cross like Mikado.
The background is this:
I've seen similar issues when exporting from 3D Studio into Collada and then importing into jME. The ColladaImporter is still relatively new and there is still quite a few things missing and bugs that need to be resolved. However, Collada is the direction we're really striving to go now as it supports much more than any other format. I would suggest if you can post some simple models in Collada that exhibit this behavior hopefully someone can help get the bugs resolved with it. The more we can do to fix the ColladaImporter the happier we'll all be in the long-run.
One of the major drawbacks of COLLADA turned out to be what they initially thought would be a major advantage. They made the specification so open ended there are multiple ways to define items of the models. This means that writing an importer becomes a major pain in the ass. It also means that since the COLLADA importer is actually a NCsoft contrib, built on their time, my number one goal is to support our exported models. Therefore, time is not on my side for making sure it supports every exporter out there. And don't worry, I'm not making excuses, the importer certainly should support every valid COLLADA file that exists, what I am doing is asking for all the help I can get. If your COLLADA file doesn't work, please, if you have time, run it through the debugger and see what tag is misses or incorrectly applies. That will cut down on the time to fix it dramatically.
I am in fact unable to create any Blender model that imports correctly into jME. This gives me hope that I just chose the wrong settings and there is an easy work-around…
The Collada 1.4 exporter settings I used are:
- Triangles yes
- only export selection no
- Bake Matrices yes
- disable physics
Mojo, I appreciate your position and since this is something that is causing me a lot of problems in my own project I'm going to have to spend some time trying to figure out how to fix the ColladaImporter to work with it. If you can get the uncommitted changes into CVS for the work you've been doing on features I'll try to resolve my issues with Maya exporting and hopefully take some time to help resolve some other issues like this one. I keep thinking to myself, "We just need someone else working on this" and I've finally figured out it's gonna have to be me.
I’ve had models more or less work from blender to jme, the only issue was a texture state that I couldn’t find or get rid of. It was correct (in terms of the image used) but I wanted to disable mipmapping and no matter what I did, I couldn’t.
Are you on the very most recent blender collada exporter from Illusoft? http://colladablender.illusoft.com/ I had lots of trouble with older versions of that.
You may also want to try “applying” everything you can in blender (scale, rotation, all transformations). Blender seems to have a similar problem to Collada in that it has a LOT of ways that something can be translated, scaled etc. and sometimes exporters will miss one of them. Messing about with stuff in blender can sometimes fix these things, especially if you are seeing more or less correct meshes, but with incorrect translation/rotation/scale.
I would also be very interested in a functioning Blender -> Collada -> jME path, since I’m using Hevee’s exporter without problems, and I would love to continue, but I accept that Collada is probably a better long term route as long as it works Even if the conclusion is that we need some fiddling about in Blender before exporting, that wouldn’t be too bad. I can dig out the more or less working blender file if it would help (I had to mess around with it to get a decent export, so when I gave up on Collada I went back to the normal version, but I think I may still have the file around).
OK, I got it working again yesterday by redoing some of the changes in Blender and re-exporting the file to Collada as described above. phew
Yes I am using the most recent stable version I could find (1.4 I believe), and apart from that one glitch I described, it works very well! Good to hear that Collada will be the format of the future. As soon as it supports animation too, I'll consider using it exclusively. Generally, thanks to everyone providing format coverters! APPLAUSE
- Another thing I have not figured out yet is textures. Currently I only see material colors in jME. The .dae file is .xml, so should the Collada exporter be exporting textures as image files, is that a supported feature? And will jME pick them up if there are in the same directory? I haven't looked into that, that's the next step.
- And another question... Since I switched to Collada, horizontal collision detection has become iffy, if not non-existant. (May be a coincidence though, other factors changed too.) The player basically runs straight through railings and walls (at the most, he is deflected or slowed down), while at the same time the ground and most of the ramps work as expected. Is there is a lower size limit, e.g. the player mustn't be too slender and walls mustn't be too thin, or so?
Glad to hear it’s working
I’m pretty sure that the image path but not the image itself will be in the Collada file and then the JME file, but there is a mechanism for overriding the location, I think it is described here http://www.jmonkeyengine.com/jmeforum/index.php?topic=3958.0. When I used Collada it actually found the image file in ModelLoader, which led to problems when I couldn’t override it It’s bad to rely on the path anyway, since I think it is absolute.
Are you using jme-physics for collision detection?
You can always override the path when you load it.
Do you have a suggestion for making ModelLoader support multiple paths for textures?
Being stupid, I read that wrong the first time and I thought you meant about overriding location with "TextureKey.setOveridingLocation(URL)" so I wrote the next paragraph, but I thought I would leave it in anyway, since I enjoy being irrelevant As far as ModelLoader goes… I'm not sure, maybe keep the texture path in a properties file so it persists, with a file dialog shown when you press a key? Then if ModelLoader is being used as part of a workflow for checking models (which it is good for the user could just set their texture path once and it would hang about. When you say paths, can you set multiple overriding paths? That would be a good thing to go along with the feature in the next paragraph, to have a list of paths to be checked in order, like the Java classpath.
So the irrelevant bit: My feeling the last time the paths thing came up was just to allow for partial paths from a single root, so that textures could be organised in subdirectories. I have no idea how to make that work, I'm just thinking of the Java classloader "getResource" type thing, which is relative but can still contain directories as part of the path, like "/planes/light/chimera/wingTexture.png" rather than "chimeraWingTexture.png" in the same folder as a huge pile of other textures It would make it easier to have stuff like mission packs as well, since they could sit in their own directories in the top level resource directory, and not run into each other's naming spaces ("/bobsMissionPack/explosion2.png" and "/bertsMissionPack/explosion2.png". It's not all THAT unlikely that both Bob and Bert will provide a new explosion texture, and fail to be very imaginative with the naming
In fact, I think I am being REALLY stupid here - is there any reason at all why the overriding url can't just be a relative path to be used with getResource? Then it would work with jars on the classpath as well, and do more sophisticated relative paths, paths into jars, etc.