Aller au contenu

Photo

Lightwave import-export plugin


  • Veuillez vous connecter pour répondre
13 réponses à ce sujet

#1
tmp7704

tmp7704
  • Members
  • 11 156 messages
http://social.biowar...m/project/2246/


Installation
------------
Add the plugin file to Lightwave Modeler -- this is typically done using "Add Plugins" command in the Modeler and then pointing the Modeler to location of the plugin file. Once added, the plugin adds a new command to Modeler interface: "Export Bioware Mesh as XML". The command typically shows in list of installed plugins under "Additional" but can be placed wherever it's most suitable using "Edit Menu Layout..." function.

In order to function the plugin may require installation of "Microsoft Visual C++ 2008 Redistributable Package". Install this package if you receive an error about missing DLL when you try to use the plugin. It's available at http://www.microsoft...&displaylang=en


Import
------
With the plugin installed Lightwave gains ability to import BioWare .mmh and .msh files simply using the "Load Object" command. Please note while Lightwave will import vertex maps and colour maps from the mesh file neither of these is enabled by default in the imported object.

Additionally while import creates all surfaces applied to original mesh, it does not automatically import surface parameters like applied image maps. That's because information about the materials is stored in other file types -- namely .mao files. Import of information stored in these file is planned but not currently supported.


Export
------
Procedure to export data from Modeler to Bioware Mesh file is as follows:

* in Modeler, select the layer with data you want to export

* invoke command "Export Bioware Mesh as XML"

* in requester which opens choose a directory and file name for your export. It's practical to give the file extension of ".msh.xml"

* once the .xml file is generated it can be turned into binary .msh file with help of GraphicsProcessorMSH utility which typically ships as part of original DA Toolset


notes about export:

* only data from first selected layer in Modeler is exported.

* only regular geometry is exported. To export SubPatch geometry Freeze it first.

* the name of surface applied to model is retained on export. DA will use this name to apply its shaders to geometry, as defined in associated .mmh file

* the export procedure ignores the vertex normal map data and instead calculates vertex normals based on "smooth threshold" attribute as defined for each surface. Since Lightwave doesn't have "smooth group" functionality from other 3d programs, this functionality can be to a degree emulated by assigning different Part information to the polygons -- if two polygons don't have assigned the same Part, the edge/vertex shared by them won't be smoothed.

* vertex colour information is supported and handled on per-surface basis. Surfaces with applied vertex colour map will have this data exported, surfaces lacking assigned vertex colour map will be exported without this data.

* models with more than one surface are supported. Each active (used) surfaces creates a sub-part in the .xml file.

* discontinuous vertex maps are supported.

* multiple UV maps per vertex are supported. The maps are exported in order determined from their names -- to handle that the exporter looks for a number at end of map name. E.g. a map named "UVmap 0" will be followed by map named "map 1" and then "UV_map_2" etc.

* multiple weight maps per vertex are supported. However to conform with target file format the export procedure will automatically select 4 maps with strongest influence per vertex and ignore any additional map associated with the vertex.

* the index for each weight/uv map is deduced from a number expected at the end of map name. I.e. a map named "bone13" will be given index of 13 in the exported file. This allows to either add geometry to imported .msh files, or to create entirely new models which can properly use skeleton and animation information defined in already existing .mmh files.

* because the export procedure is currently limited to producing .msh files, vertices can only be assigned weight maps which are created by import of existing .mmh file. In other words, full procedure to create a new mesh would be as follows:

- pick and import existing .mmh file with item of similar type you're going to create.

- once the model is imported and associated weight maps are created, build your model either by editing existing mesh or with new geometry. Assign existing weight maps to the vertices, and existing surfaces to the polygons.

- export the .msh.xml file and convert it to binary .msh using the GraphicsProcessorMSH tool. Use existing mesh name if it's supposed to be straightforward replacement, or your own if it's a new item

- for a new item make a copy of originally imported .mmh file and adjust its content with GFF editor of the Toolset -
- replace link to original .msh with name of your own .msh file, and if suitable/needed replace links to material .mao files with names of your own .mao files.

- adding a new item generally requires changes to other game files (.2da sheets and such) which are beyond scope of this .readme -- look for tutorials on web and DA forums for details of that procedure.

Modifié par tmp7704, 16 avril 2010 - 02:29 .


#2
Eshme

Eshme
  • Members
  • 756 messages
If you mind me meantioning the index. I dont know how far you figured this one out yet? Did you speak about Bone index?

#3
tmp7704

tmp7704
  • Members
  • 11 156 messages
Yes. To be exact, what i meant was: the *.msh files don't have full information about the model skeleton, just a reference in the form "this vertex is affected in 50% by bone number 6, 25% by bone number 10 and 25% by bone number 29". That means for the export purposes the program has to be somehow told that "bone X" should be referred to by number 6 and "bone Y" by number 10 or whatever.



When/if i get around to adding import/export of *.mmh files the weight map assignment can be made less explicit but until then it'll have to do... and it's not really much of issue in practice, from my experience so far.

#4
ChewyGumball

ChewyGumball
  • Members
  • 282 messages
Indeed. It really need not be too explicit at all. As long as the index matches between the mmh and msh, it can be any number you want.

#5
tmp7704

tmp7704
  • Members
  • 11 156 messages
Small update.

Image IPB

added basic support for import of *.mmh files -- loading file of this type will re-create the skeleton structure described in it, and the weight maps will now have less cryptic names.

also added export of colour vertex data to exporter module. The data will be exported for surfaces/parts which have the colour map assigned, and skipped for surfaces which lack such assignment (since most of typical items appears to skip it as well, to conserve the memory and whatnot)

#6
Eshme

Eshme
  • Members
  • 756 messages
Hmm i wonder ,what is the spikey bones going of the hips? I dont get them in my importer.

#7
tmp7704

tmp7704
  • Members
  • 11 156 messages
They are named RightPlate, LeftPlate, FrontPlate and BackPlate and parented to Pelvis bone. Maybe some armour types simply don't include them? This one was pulled from file ef_arm_lgtb_0.mmh (which seems to only utilize the FrontPlate bone to some degree)

Modifié par tmp7704, 17 avril 2010 - 01:38 .


#8
Eshme

Eshme
  • Members
  • 756 messages
Oh ah yea i get them then all the time. They are floating little bones for me from the tip of your spikes lol.

I dont know the use really

#9
tmp7704

tmp7704
  • Members
  • 11 156 messages
Ah maybe Lightwave uses different way to draw the bones than Max then, no idea really -- the way Lightwave does it is to draw the bone from its parent to the point where the bone technically is. So from description these floating thingies at the tip would seem to match that.

I'd guess they are mostly used to animate these plate things that hang on some heavy armours, to ensure they don't clip into main armour mesh when character walks around, or something like that.

Modifié par tmp7704, 17 avril 2010 - 01:57 .


#10
Eshme

Eshme
  • Members
  • 756 messages
Yup seems like it. I set a tiny default lenght or something for end bones, because they have no end then. But that is ok.

FBX import does what you do. It is some helpers, but the bone points backwards which i found a way ackward to see and work with envelopes and the like. But this is a 3ds thing.

#11
Eshme

Eshme
  • Members
  • 756 messages
BTW if you need help decrypting some of the weird stuff in Bioware files i can help i have solved many riddles togethr with Newbypower

#12
tmp7704

tmp7704
  • Members
  • 11 156 messages

Eshme wrote...

Yup seems like it. I set a tiny default lenght or something for end bones, because they have no end then.

Ahh. hmm actually in this case i'm not 100% sure (not having enough experience with Max, it was ages ago i touched it) but you may be "doing it wrong" so to speak -- the thing is, a "bone" is basically just a point, with position of this point determined by offset and rotation from its parent "bone" (also a point), similar to how Lightwave draws it in that screenshot.  If that bone is an end of chain then there shouldn't be really anything sticking past that point -- that point is end of the bone, not its beginning (the beginning would be where its parent bone is/"ends")

Or to put it differently, when you build the skeleton it should start with exactly one extra point from which you draw to the point defined by the root bone of your skeleton. This extra point being the 0,0,0 spot in your scene space, because that's what the root bone precisely is -- an offset and rotation from the 'world' origin. If you do it this way, then it'll likely result in similar drawing you can see in the screenshot, with the plate bones looking like spikes.

... unless Max really does it different, in which case please disregard this Image IPB

Modifié par tmp7704, 17 avril 2010 - 03:15 .


#13
Eshme

Eshme
  • Members
  • 756 messages
Yep it is different in visuals, internally its the same. The end is really only a lenght property the deformable maxbone mesh has.

This makes it so that while the upper leg bone is in the hip, it ends in the knee. What you select basically, you get what you select lol. This way you dont select the hip to get the leg like with FBX importing.

#14
tmp7704

tmp7704
  • Members
  • 11 156 messages
Ahh yup, the default approach can be quite confusing if the naming scheme is like what DA uses -- e.g. the bone they have named "ankle" would be more intuitive if it was instead named "shin" and so on.