DeleD Community Edition

[Paul-Jan]

Multiverse Exporter

Sometimes, the development process feels like a huge black box: user input goes in into one side, and a whole lot later (insert sound of slow grinding cogs here) a piece of software comes out that may or not live up to the original request. A long wait for the user, not too much fun for the developer either.

As a little experiment, I'll take a slightly different approach to developing our new Multiverse Exporter, and keep a development log here. That'll give interested users a chance to watch it progress and to give feedback at an early stage, and for me it'll be a nice reminder to keep development at a steady pace.

You can find the latest development snapshot here.

Be warned: this is not a finished product. It may not work properly, it may not work at all, it definitely is missing important functionality, and for all I know it might explode in a great ball of fire causing structural damage to your hardware, house and vital organs. Like I said, be warned.

Mission
Our primary goal is to make an exporter that gets your assets into the Multiverse World Editor with as little hassle as possible. This implies that we'll need to directly export into the Multiverse Asset Repository, in a file format the World Editor understands, skipping the Asset Importer altogether.

A secondary goal could be to make sure we do not get in the way of efficient asset management (mixing resources for multiple meshes into a single asset, things like that), but I'll postpone that to a later stage.

Interface



So far, the interface is still really simple
1. Fill in an asset name
2. Select an asset repository. This field will be initialized to the designated asset repository from the Multiverse toolset, unless you specify a different folder. In that case the folder you specified will be remembered until you hit the refresh button to the right of the field.
3. Select a scale
4. Press OK. Done.

The good news is it basically works. Mesh, materials and textures get exported to the correct folders within the selected asset repository. Furthermore, an asset definition for both the mesh and the material (called [name]_Mesh.asset and [name]_Material.asset) get exported. I can actually select the object from the World Editor and place it in the scene.

Misc screenshots


The (in)famous CastleSiege model inside the World Editor.

Things to do
- Test support for OBB, implement capsule collision volumes.
- The mesh is exported in the Ogre 1.36 format, could it be important to move on to the latest format? (AFAIK, the answer is "nope, works fine.")
- The filenames used to store mesh, materials, textures and asset definitions are always based on the asset name, and bluntly overwrite any existing files. We should at least signal this the user, optionally allowing them to pick different names.
- I currently write the asset name into the <description> field of the asset definition, this is probably not what is supposed to be in there...
- The categories are currently hardcoded. Where does the Multiverse toolset store them and how do read them from there?
- Normals, should be possible to be set them to face/smooth/auto crease angle.
- Option to choose whether lightmapped materials should be affected by dynamic lights.
- Material names are prefixed with the mesh name to make them unique... must improve material handling at some point.

[Starnick]

The .physics file requires user-defined collision meshes as mentioned in that first thread I started.

I brought this up over at the MV forums:

http://update.multiverse.net/forum/viewtopic.php?p=25519&theme=multiverse#25519

Great Job so far! You're going to have the thanks of many people over there who do not like to use blender (and can't use maya/3DS for fiscal reasons)

[yanchiko]

Interesting,my only question:
Multiverse uses a binary file formats based on OGRE for 3D models. Several files define a model.So the exporter is designed for "OGRE users" only?.

[Starnick]

[Paul-Jan]

Starnick: I am considering assisting the user a little in defining those collision meshes. For instance I could offer some sensible defaults, like the convex hulls or bounding boxes of your primitives, so you can get to actually use your assets a.s.a.p., and worry about the details (tweaking your collission mesh to perfect fit) later. Thanks for the 'link love' at the Multiverse forums!

Yanchiko: I don't think I really understand your question, sorry? The exporter currently does export an ogre-like binary format. It uses the same codebase as the Ogre exporter, it just exports everything to the locations prescribed by the Multiverse toolset, and then generates proper asset definitions. Seems to work just fine thus far.

[Starnick]

[quote="Paul-Jan"]Starnick: I am considering assisting the user a little in defining those collision meshes. For instance I could offer some sensible defaults, like the convex hulls or bounding boxes of your primitives, so you can get to actually use your assets a.s.a.p., and worry about the details (tweaking your collission mesh to perfect fit) later. Thanks for the 'link love' at the Multiverse forums!/quote]

That's a great idea =D

[Paul-Jan]

Update: I spend some time getting a local client+server setup installed. Quite a technical process, but nothing too bad, considering I am setting up a full MMORPG server.... then again, note how I am not in the least interested in actually running said server, not even in running the client*... All I'm interested in is testing collision volumes, and apparently there is not other way to do so than through the client.

I think this is a a flaw in the existing toolset. Artists should be able to test their collision volumes without having access to a running Multiverse server (it's not like your average artist is going to be very comfortable setting up local MySQL databases and installing JDBC drivers). Also, you have to restart the server (I think) and client everytime you apply changes to a model to testdrive the physics. Not very good.

I think that if you take the all-collada route things get slightly better, because then you might get to preview your collision volumes inside the Model Viewer... but I'm not taking that path as it requires an extra conversion step to get the final model format.

Another small disappointment was the limited set of supported collision volumes. OBB, AABB, spheres, capsules... and that's it, so no convex hulls (unless I construct them from OBB's, which would be rather inefficient). The exporter will match cube primitives to AABB and OBB (when rotated), spheres to spheres, and have the exporter ignore everything else (with a warning).

Enough about that, on to the actual physics format: I am not 100% sure yet how to relate collision volumes to the so-called 'submeshes' . The thing is our primitives do not directly correspond to submeshes (submeshes only contain a single material), they get processed and split-up into them. However, I am guessing the exact match-up is not really important as we are doing static models here, and all Multiverse is using it for is collision, not full-fledged physics...

Another question is how to best relate collision volumes to primitives in the DeleD interface. The cleanest way would be the use the Object Property and have users type in two key-value pairs for each volume
1. type: collision (perhaps even the volumne type, like 'AABB' or 'capsule'.)
2. primitive: name (name of primitive it is linked to)
This is the cleanest, but perhaps also the most cumbersome approach. Another approach would be
1. Have the user define a material called 'collision' (a nice translucent red would be ideal, but that's all up to the user). Every primitive completely textured with it will be picked up by the exporter as a collision volume.
2. Use a naming scheme like primitivename_collision to quickly match collision volumes with their primitives.

Not sure yet which one to pick. Will experiment.

* Ok, I'm lying here. The stuff is great and I love to play around with it. However, let's pretend for argument's sake...

[Starnick]

Yeah, I hear you on some of the difficulties involved. At least, there's some recourse (not so much with models...) of having the client being able to go into a stand alone mode. However, from what I've heard the v1.0 release had this feature bugged, plus I don't believe you can add anything to the world that is generated offline. BUT its supposed to be good to test out the UI as you're making it (even then, you still need to know how to code...so not so good for artists either...).

You can still view everything in the model viewer, if you set up an asset repository, and import the mesh with its references to textures/physics, etc. Of course, you need an exporter to spit out all the correct files...correctly, but you would still need that anyways if you wanted to test CV's in a world (although its best that way anyways...).

[Paul-Jan]

Starnick: If you export the mesh as a collada file, you can indeed preview the CV's in the model viewer, but not if you export directly into the native mesh format, physics file and an asset definitions. AFAIK the model viewer doesn't actually read the asset definitions, I really need the client for that.

Update: I've got the axis aligned bounding boxes working nicely. Will post some details and screenshorts shortly, but I'm too tired right now. Due to severe brain malfunction I can't seem to get the math working to convert OBB's from 8 vertices (DeleD representation) to center+rotation+extents representation as used in the .physics files. I'm sure it will work out though.

[Starnick]

Something from the developer grapevine over there:

http://update.multiverse.net/forum/viewtopic.php?t=3703&theme=multiverse

They're working on having CV's automatically generated, no specific dates other than possibly early part of next year. First time I've seen them say that, heh.

[Paul-Jan]

Hah, that's good news, thanks for the update. I'm not completely sure how they are to do that though, because 'cheating' on the collision volumes (like setting a really coarse collision volume on the roof of your buildings) is probably key to getting high performance in any MMO.

For now, I'll settle for manually defined volumes in our toolchain, and add a little tool to DeleD itself to assist in CV creation.

Development Update: Spherical CV's are now working nicely too.

[Starnick]

Any updates as of recent?

[Paul-Jan]

Sorry for the sudden quiet, I've been away from the forums for some time (doing crunch time for a deadline at the dayjob)... but I'm back now, and I'll be releasing a first usable (hopefully) version of the exporter over the next couple of days.

[Paul-Jan]

Some technical stuff I did today:
- Resolved material name clashing by prefixing materials with the mesh name, making them unique. This will of course result in a lot of duplicated materials in your world, but it works as a quick solution. If anyone has a suggestion on how to handle this (material management) properly I'm all ears!
- There is no need to connect collision volumes to specific primitives, as there isn't any animation involved. I just connect all volumes to the first primitive in the scene. Generating the "sid" for this submesh was a bit tricky, as it turns out an ogre mesh doesn't have any names stored inside it, so the Multiverse toolset just makes one up. Meshname + '_SubMesh1' works fine.
- Still testing OBB generation (generating the correct OBB data from marked cube primitives), but things seem to work properly now...

Just for good measure, I'll throw in a screenshot:



Mr Fletcher's Frauenkirche model running inside the client... note how the only reason I turned on collision volumes here is to hide the fact that I am running around with a naked female avatar that for some reason I can't seem to get rid of.

[granada]

Love that model .

Dave
_________________
AMD Phenom(tm)IIx6 1090t Processor 3.20 GHS
8.00 GB memory
Windows 7 64 bit
Nvida Geforce GTX 580