[Pipeline] DeleD Importer
Project name: DeleD Importer
Project Type: Importer API
License: New BSD
Link: http://code.google.com/p/deledimporter/
Recruiting: No
Contact: Private Message
Hi all, some may remember my first release of a DeleD to Jme converter. A while back I decided to refactor and improve that code tremendously while adding new features. I also sought to not just create a model converter, but establish an extensible 3D pipeline from DeleD. Well here it is and I feel it’s about time to post a link to the source code and explain it a bit.
I do not think many here use DeleD, but it’s a great little modeling tool (there’s an unrestricted free version, just doesn’t have some CSG functions, lightmapping, and a few tidbits I don’t even use in my PRO version). It’s an alternative to blender in my opinion as its easy to use, and also is geared to be somewhat of a level editor. My goal with this revision of my importer was to leverage that support.
A link to DeleD’s home page: http://www.delgine.com
Features:
Basic
* Imports:
o Geometry
o Lights - Spot, Directional, Point.
o Color Materials (one layer only).
o Texture Materials (up to three layers).
* Automatically triangulates polygons.
* Automatically splits meshes with multiple materials (only 1 material per primitive).
* Support for jMonkey 2.0 Engine.
Advanced
* Plugin system that allows users to define and import custom scene elements
* The following example plugins:
o Light Node extension
o Attachment Point extension
Planned
* Animation and skeleton support.
* Support for Ardor3D Engine.
Overview:
DeleD Importer has these goals in mind:
- Modularity and re-usable components
- Extension
It's still a bit work in progress, but its structure and organization is fairly stable by now. The pipeline has two major components:
- DXSImporter class
- Format interface
The DXSImporter which parses DeleD's XML based .dxs file. This creates an internal representation (nodes, primitives, lights, etc). It's entirely separate from jMonkey, whifch is intended. I plan on using this for both jMonkey -and- Ardor3D support (betting other java engines can be used).
The DXSImporter class also takes in an object that implements the Format interface. Through this interface, the internal DXS data will actually be loaded into the specific format dictated by the interface implementation. So in terms of jMonkey, in this class you'd have all the DXS-specific objects converted into their respective jme scene objects. When the importing is complete, you'd be able to extract the model data from the format and attach it to your scene.
Other than the idea of supporting multiple engines (which means I can support jME 3.0 easily by just writing a Format implementation for that, and without touching the importer code, or changing the importer code as DeleD is improved but leaving format implementations intact), this separation allows for users to customize the importer greatly.
As the DXSImporter parses the XML data of the .dxs file, it will execute registered extensions that the user provides. This allows the user to inject code for custom scene elements.
An example use case for attachment points:
- User creates a class "AttachmentPoint" and extends DXSSpatial (analogous to a jme spatial)
Say attachment points are defined as cubes in deled where it's center is the attachment point location,
and its name is prefixed with "attp_" (e.g. "attp_leftWeapon") which identifies it as an attachment point
- User creates an extension that looks for that prefix while the importer parses scene elements, and if found
creates the appropriate object and attaches it to the internal representation
- User then creates or subclasses an existing format and defines how the attachment point should be converted.
Actually this step and step 1 may not be needed. If you treat attachment points as just nodes with unique names,
you can just leave it at that (and use DXSNode in the extension) and the default jme format will convert it into a regular node. If there was no extension, then you'd be left with a trimesh named "attp_leftWeapon"
So you're able to customize the importer with your own dxs elements -and- convert them into your own jme elements (as well as the standard scenegraph classes)
Similar approaches would be used for other types of extensions, like spawn points, trigger points, collision volumes (something I'm working on), etc. In this way, I could use DeleD more like a level editor and less like a modeling tool (not everything need to be name based, as deled allows custom key/name tags for objects, vertices, etc.). It's all up to how you customize it, and what your needs are.
Concluding Remarks
The point is to have the ability to use DeleD to define custom elements rather than slapping it together manually while working inside your code (e.g. If you have a starship that's supposed to fire lasers from a weapon barrel, rather than estimating where to place a node that represents an attachment point (or an emitter of sorts), why can't you just define it in DeleD, and place it perfectly the first time?).
Anyways, that concludes my little explanation. The code is still a little spotty in some areas (Ardor3D support consists of stubbs for example). There are some limitations, though they reside mostly with DeleD - e.g. you can't really define a scene hierarchy in DeleD, so most likely you're going to have all your scene elements attached to the root node returned by the importer. You could get around this by re-organizing things when the Format implementation loads the data (e.g. after conversion, you group all similarly tagged attachment points, meshes, etc together under one node).
For those who are interested or are using DeleD, I hope this may be useful, it is certainly for me and that's why I decided to release it. The code's well documented, and hopefully this post and the examples in the code are self-explanatory. Be mindful some parts are still under testing.
Also a note on the SVN organization:
There are three eclipse projects there, first is the ardor one (which is full of stubs). Second is the DeleDImporter project, this contains the importer and internal representation classes. Third is the Jme project, which consists of the jme-specific format implementations and examples using the importer.