If the plug-in will reach a decent state i’ll probably switch to a dedicated repository.
What’s the parser does:
parser structure
scene loading
node tree with transforms (shear not supported yet)
geometric elements defined via polygons, polylist, triangles, supports position, normal, binormal, texcoord, tangents (for polygons just simple convex ones will work because of fan-triangulation)
lights
lambert-phong-blinn materials (shadeless, no transparency yet)
measuring unit conversion
What's will do next:
skinning, animations, up direction, better shaders for materials
How to test.
Compilation produces a jme3dae.jar file. Include that jme3dae.jar file in the classpath of the test project. Start the application with the option:
-Dchecksenabled=true
to see debug info (a lot of weird "todo" messages).
Before to load a dae file in your program, register (once) the collada loader as loader for dae extension in the asset manager:
Note: the parser is supposed to work for what it does.
If usage results in an exception then it's a bug.
If usage results in a scene that doesn't look like it had to be, it could be a bug or a missing feature. A missing feature is signaled with a todo message in the command line.
Suggestions, comments, critiques and alike are always welcome.
Cool, although I am afraid of putting it into jme3… The format is very convoluted and I guess it will be a pain to update/extend the importer. I'd like to see fewer importers in the core engine. Importing / conversion is something that should have happened before the game is started. So I'd propose making this an import plugin for jMP instead of putting it directly to the jme3 core.
It's good to support this format, but it's scary because we could get a lot of complaints if it doesn't work with Modelling Tool X, Feature Y, and export plugin Z… it could be a lot of work to maintain it. But if you're willing to put the effort then its good
As Kirill already knows (and I think might hate me for ^^), I'm kind of a COLLADA proponent and have been using the format for a while. The project I'm working on for the next two years also has kind of a heavy basis in the format as well so this is something that I'd be willing to help work on.
normen said:
Cool, although I am afraid of putting it into jme3.. The format is very convoluted and I guess it will be a pain to update/extend the importer. I'd like to see fewer importers in the core engine. Importing / conversion is something that should have happened before the game is started. So I'd propose making this an import plugin for jMP instead of putting it directly to the jme3 core.
You might be interested in a paper I read that makes [what I think is] a rather good argument for an import based pipeline. Granted we have that already but some folks are as loyal to 3D formats as they are to IDE's based on the art pipeline tools that they're already using.
Obviously we definitely aren't an export based pipeline, we're slowly creeping towards that mentality by virtue of such tight integration with a single format IMO
Obviously we definitely aren't an export based pipeline, we're slowly creeping towards that mentality by virtue of such tight integration with a single format IMO
Its not exactly true. Ogre3D can be exported from many modelling tools. If we support multiple formats like jME1/2 we risk having fragmentation, too many systems etc.
I think ogre format support is fine. The only reason why I'm exploring collada is because I'm unable to export a scene from Blender to ogre format without going crazy. Ideally the problem could be solved by tuning the blender-ogre plugin but i have to admit that I like python as much as I liked the way Italy played against New Zealand: during the first time I tried to make harakiri with the remote control, unfortunately I failed and had to watch the second time too.
Momoko_Fan said: (...)If we support multiple formats like jME1/2 we risk having fragmentation, too many systems etc.
There's no risk so long as you the developers are committed to a single format, leaving the rest to third parties such as community developers the likes of pgi. If he does a good job with the collada loader, we should condone that contribution, making it easy to come by through our site. That's not to say from then on we'd have to promise our users jME3 would always come with an up to date collada loader, nor market it as such.
@pgi: Football has been almost hurtfully unpredictable this year :(
Manually setting the material name, the two step process to export a scene, the odds of the resulting ogre material (if your blender material has one or more textures will the ogre material have it? Surprisingly, not always).
I think the dae exporter has the same problems with blender materials (textures are exported only if mapped to color).
Manually setting the material name, the two step process to export a scene, the odds of the resulting ogre material (if your blender material has one or more textures will the ogre material have it? Surprisingly, not always).
I think the dae exporter has the same problems with blender materials (textures are exported only if mapped to color).
That's weird.. I've had pretty good luck coming out of Maya with the textures :/
With regards to the parser structure, it makes enough sense to me. Let me know if/how I can be of help in working on it!
@sbook I read your article and it was very interesting. With jMP I try to solve some of the presented problems and I agree that having the importers directly in the engine might solve some of these but…
In jme3 we can not even with the ogrexml format store every aspect of what the jme scenegraph can do so we would basically limit the capabilities of the game models to those of the import formats. When exporting models we would have to use all kinds of jme-specific meta tags etc. to store all jme-relevant data.
Also, we would have to define how extension info is stored (physics etc.) for each format so people can extend it and jme understands. With the current implementation you just extend spatial and its good…
I am very interested in more opinions and input about this as this is especially interesting for jMP. Right now its headed for a j3o-based workflow due to the problems I mentioned. It would handle the "original ogrexml" files, check for changes and update etc…
sbook said: Let me know if/how I can be of help in working on it!
Well, i'm a huge fan of the "10 fingers, many brains" methodology. I've got the fingers, i need the brains.
A couple of questions.
1. A feature of collada that i would like to preserve is the face-material mapping of meshes (a single mesh with multiple materials applied to different faces). This situation arises for example when we assign different materials to different faces of a single mesh. How to translate that in JME3?
2. Collada node elements belong to layers. Should we preserve that feature? If so, what could be the best jme3 technique to do so? Mapping layers to jme 3 nodes and assigning collada root nodes to jme layers-nodes? Do I have to create a "layered" jme3 node or it would be better to return multiple Node from one collada document with more layers?
3. A collada scene can have multiple cameras. JME uses one camera but if we take for granted that just one collada camera will be active at a point in time we could map collada instance-camera elements to jme-camera settings (location/orientation/fow/near/far), letting the program to switch among them. That can be done introducing a specific collada-jme3 element (maybe a CameraSwitchSet, holding different CameraSwitch object that once activated simple assigns to the jme camera the values taken from the corresponding collada element). Any better idea?
1. A feature of collada that i would like to preserve is the face-material mapping of meshes (a single mesh with multiple materials applied to different faces). This situation arises for example when we assign different materials to different faces of a single mesh. How to translate that in JME3?
It's simple: Just have a mesh per material, then "push" triangles into the mesh corresponding to the triangle's material.
pgi said:
2. Collada node elements belong to layers. Should we preserve that feature? If so, what could be the best jme3 technique to do so? Mapping layers to jme 3 nodes and assigning collada root nodes to jme layers-nodes? Do I have to create a "layered" jme3 node or it would be better to return multiple Node from one collada document with more layers?
What do layers represent in collada? What is their purpose exactly?
If parsing a collada results in multiple nodes, you can just put all of them into a single node that represents the entire file.
pgi said:
3. A collada scene can have multiple cameras. JME uses one camera but if we take for granted that just one collada camera will be active at a point in time we could map collada instance-camera elements to jme-camera settings (location/orientation/fow/near/far), letting the program to switch among them. That can be done introducing a specific collada-jme3 element (maybe a CameraSwitchSet, holding different CameraSwitch object that once activated simple assigns to the jme camera the values taken from the corresponding collada element). Any better idea?
At some point CameraNode will be available in jME3. The CameraNode will allow storage of camera settings right inside the scene graph. You will be able to use this node type to store the cameras.
The user could then locate a specific CameraNode by searching its name in the scene graph.
Momoko_Fan said: What do layers represent in collada? What is their purpose exactly?
If parsing a collada results in multiple nodes, you can just put all of them into a single node that represents the entire file.
The specs are not particularly precise. A node can have a list of names where each name represents a "layer". So if the node has a {a, b, c} layer's list it belongs to the layers a, b, and c. Eg:
The problem is that there is no state for these "layers", that is why i think to them as unrelated groups of elements (because there's no value that says "ok, i'm the visible layer", or "the visible scene is the combination of the L11 and L14 layers").
collada calls "phong" the fixed function pipeline for materials. It is the classic "setAmbient - diffuse - specular etc" colors, plus refraction, reflection, transparency and an optional texture for each "color".
