How are coded the md3 tags in Blender ?

Scripting in Blender with Python, and working on the API

Moderators: jesterKing, stiv

Posts: 8
Joined: Tue Jul 01, 2003 10:41 am

How are coded the md3 tags in Blender ?

Postby c-leo » Tue Jul 15, 2003 12:28 pm

Hi, i'm writing an export script into md3
the md3 format stores tags, which represents the link between two md3 objects. I would like knowing how these tags work in Blender. I need to get
the position of an object, relative to another, and the rotation matrix

What is a parent object?
and a tracked object?

Posts: 1000
Joined: Tue Feb 25, 2003 2:37 pm

Postby ideasman » Tue Jul 15, 2003 3:09 pm

I will try to answer your questions, not knowing the md3 format.

You will need to read the docs about getting the matrix and rotation.
You should be able to work out relative position just by getting both pos's and working it out.

I dont think these tags do 'work' in blender.
You will need to get the data to make the tags, then write them.

A parent is an object that when moved/rodated, all its children move with it.
to access a parent object use
parent = someObject.getParent()

Tracking is when one object rotates to face another (Often used to make the camera follow an object)
I doubt weather you would need tracking for an md3 exporter.

Good luck with your exporter, announce it once you get somthing going.

Posts: 216
Joined: Thu May 29, 2003 10:32 pm
Location: Maryland, U.S.

Postby ascotan » Sat Jul 19, 2003 3:59 pm

I have some experience with the .md3 format. I modified phaeonH?'s script to import the 1st frame of the .md3 file into blender using the current version of blender (got rid of all the calls to blender210). It uses a tkinter interface though because they axed the fileSelector module. I really would like to create a good .md3, .mdc and .mds importer/exporter for blender. The problem is that the python api is just not robust enough yet to do the dirty deads. The .md3/.mdc file formats are vertex keyframed while the .mds format is armature modeled and bone weighted. These formats are for RTCW. Theyre all derivatives of the original Quake3Area .md3 model format. If you need any help I be happy to see what I can do. I wrote an dll importer for .mds player models in milkshape3D but the proggy does have bone weighting and they still dont support vertex animation. Blender does! But it does not make these accessable through the api yet GRRR! The tags in the .md3 file format are typically a right triangle. It defines and xyz origin in space. In Milkshape the orientation of the triangle is important. It looks like this... The reason for this is most likely that the .md3 exporter finds any mesh starting with the name tag_xxx and then checks if the mesh is a triangle and then calculates its orientation. Oh, btw it shouldn't be an isosceles - so you can tell which side faces which axis. You would need to make this a separate surface/mesh in blender and name it such as tag_xxx. The .md3 file format maintains a list of tag objects in the file. Each tag object is defined as :
U8 * MAX_QPATH NAME Name of Tag object. ASCII character string, NUL-terminated (C-style). Current value of MAX_QPATH is 64.
VEC3 ORIGIN Coordinates of Tag object.
VEC3 * 3 AXIS Orientation of Tag object. (XXX: more descr)

So by naming the tag as tag_xxx your script will not save the mesh but only save the name, origin and orientation (vec3 is a float[3]) of the tag. The mesh will disappear. When you reimport the model you would need to create a mesh based on the tag info so that you could manipulate it later.... :) So as for the rotation matrix etc.... The Quake engine uses its own scripting language to attach models be they player or otherwise... You would write a script for the Quake engine and add the following statement... model1 attachtotag<tag_xxx> or such. So all you would do is make your individual models and export them with tags... then in Quake you would write the script to attach them. As for the orientation of attachment it depends on 2 things. 1. The orientation of the tag 2. the orientation/position of the local origin of the model that is being attached in frame 1. If you look at the .md3 format frame object it looks like this:
Datatype name/purpose Description
VEC3 MIN_BOUNDS First corner of the bounding box.
VEC3 MAX_BOUNDS Second corner of the bounding box.
VEC3 LOCAL_ORIGIN Local origin, usually (0, 0, 0).
F32 RADIUS Radius of bounding sphere.
U8 * 16 NAME Name of Frame. ASCII character string, NUL-terminated (C-style).
The model with be attached with its local origin at the tag placement..... The bounding box will tell quake where the model is in relation to the local origin. So when you export the attachment model you need to position it carefully around the local axis because this is where the attachment point will be. Hope this helps :shock:
Well whenever they get all the keyframing and armatures/bone weights worked out well have the quake crowd using blender for object modeling :D

Posts: 8
Joined: Tue Jul 01, 2003 10:41 am

Postby c-leo » Fri Jul 25, 2003 4:52 pm

thank you very much for these explanations and the time spent to answer

Return to “Python”

Who is online

Users browsing this forum: No registered users and 0 guests