StarCraft 2

Soon the new Starcraft 2 will come out and that's something big for the most people in the world and as we always do... we discuss it so lets start...


i think its a pretty good game and its focusing on making custom maps.. i was thinking of buying the collecter editon that il get starcraft 2 + Starcraft 1 + expansion that sounds like a pretty good deal if you ask me

lets get the cover up
#Edit: Found real front cover for both Normal Starcraft 2 and the collecter edition
Normal:

Collecter Edition:



And Here Is The Trailer:


Release Date:
27 of July

meh idk if im gonna buy sc2, I really want to stay with wc3, but if they have an even more powerful editor I might switch over, I heard you can make a first person system on it, if thats the case im so buying it

you can thats the best of it its a totally new way to make custom maps

do you know what the model format is to import into sc2? cause Im probably gonna take up model making and model a character that ive wanted to model for a long time

hmm i will try research on it im gonna write in here when i know

ok, i heard its some new format like .mldv or something idk

hmm ive been seaching whole 2-4 min xD... and saw something named (.M3)

#edit: ive searched some more and it looks like the format is something new called M3 hope it helps

m3, well i think ive heard about that format before, I hope its pretty HQ and detailed

hope so

Okay folks found some facts on this and im gonna post it here so you can all see it:
Part1
Overall structure

The .m3 format is a mixture of the World of Warcraft .m2 format and the Warcraft 3 .mdx format in that it has a parsing structure similar to the former, but uses tags, like the later. The list of tags with offsets are located at the end of the .m3 file. Specifically, the file header is

struct M3Header {
fourcc header_tag
uint32 tagindex_offset
uint32 tagindex_size
uint32 unknown1
uint32 unknown2
}

The header_tag should be 'MD33'. The tagindex is the aforementioned list of tags, and starts at tagindex_offset and has tagindex_size elements. I suspect that unknown1 and unknown2 may point to the tag where to start the recursive parsing, which is the 'MODL' tag. The elements of the tagindex have the form:

struct Tag {
fourcc tag
uint32 offset
uint32 repetitions
uint32 version
}

The first two elements, tag and offset, are pretty obvious I guess. The interesting part starts at the repetitions part. Each tag describes a fixed-size structure, which may be a little different for different files, hence the version number. The number of repetitions tells us how often this
structures is repeated in the chunk. As an example, a string chunk (with a 'CHAR' tag) describes a string that consists of repetitions many characters of size 1 byte (unless it's UTF8, but I've not encountered any special characters yet). This is great for loading, because we don't need dynamic parsing. We can just allocate and read the structure as many times as requested, without worrying about dynamically sized content.

If dynamic sizes are required, they are placed in a seperate chunk and referenced via the tag. Again, a good example are strings, which you can find all over the file, usually directly after the chunks where they are needed.

All chunks are padded to 16 byte boundaries using 0xaa.

Parsing

Once the tag directory has been read, my parsing starts at the 'MODL' tag (and I suspect Blizzards parsing does, too). The 'MODL' chunk is essentially the root of the parsing tree for the .m3 format, just like the header of the .m2 format, but instead of referencing the other chunks by offsets, they are referenced by their index in the tagindex. The references usually also contain the number of repetitions, which make them quite easy to spot.

That's it for today and the general parsing and file structure. Next time I'll get into the details of detecting the vertex format, reading out the vertices and faces and finally rendering a rough version of the model.

As an outlook, here are some more pictures (Templar, Ultralisk, Hydralisk):

Here is:
Part 2
Today I'll chat a little about the stored meshes. There are threed parts to rendering out simple meshes: the vertices, the faces, and the regions. But first, we need to find them.

That's where the MODL chunk comes in. It should be considered the header of the m3 format. It defines where to find what. However, we're only interested in a few parts. It's important to note that I've found two different versions of the MODL header, version 0x14 and 0x17. 0x14 is slightly different, and I'm not going to talk about it in this post.

struct MODLHeader {
uint32 stuff_we_dont_need_atm[17]
uint32 flags
uint32 vertex_data_size
uint32 vertex_tag
uint32 div_count
uint32 div_tag
[... some more data we don't care about...]
}

The precious parts here are the reference to the vertices, the reference to the div, and the flags. The flags will become handy when parsing the vertices, as they describe what can be found in the vertex format. In detail:

if flags & 0x40000 == 0:
vertex_size = 32
else:
vertex_size = 36

There are def. other information in the flags, but this is what we need right now. The vertices can now be found at the vertex tag, which is just a collection of bytes. The number of vertices is vertex_data_size / vertex_size. The format is as follows:

struct Vertex {
float32 position[3]
uint8 boneweights[4]
uint8 boneindices[4]
uint8 normal[4]
uint16 uv[2]
if vertex_size == 36: {
uint8 unknown[4]
}
uint8 tangent[4]
}

Position is just the object space position of the vertex.
Boneweights range from 0 to 255 and represent the weight factor (divided by the sum of all weights) for each bone matrix.
Boneindices are indices that point to the corresponding bone matrix.
The normal is compressed and can be extracted as c = 2*c/255.0-1 for each component.
The uvs are scaled by 2048, so they need to be divided by 2048 to be used in opengl.
Finally, the tangent is compressed in the same way as the normal.
To get the bitangent and set up a correctly oriented and orthonormal tangent space, we need to take the cross product of the normal and tangent, and then multiply it by the w component of the normal: (n.xyz cross t.xyz)*n.w

The DIV is really just a container for two other important chunks, the faces and the regions:

struct DIV {
uint32 indices_count
uint32 indices_tag
uint32 regions_count
uint32 regions_tag
[... some other stuff ...]
}

The triangles are just stored as tripplets in the indices U16_ tag. There are indices_count/3 triangles in the mesh.
To correctly render the mesh, we also need the region chunk:

struct Region {
uint32 unknown -- Note: updated, thanks to NiNtoxicated!
uint16 vertex_offset
uint16 vertex_count
uint32 index_offset
uint32 index_count
uint8 unknown[12]
}

Now, to render a mesh, we can iterate through all regions, and for each region, we render index_count/3 triangles with the indices from the indices chunk. This looks something like this:
def drawModel(self):
for region in div.regions:
GL.glBegin(GL_TRIANGLES)
for i in range(region.index_count):
v = vertices[div.indices[region.index_offset+i]]
GL.glTexCoord(v.uv[0]/2048.0, v.uv[1]/2048.0)
GL.glVertex(v.position[0], v.position[1], v.position[2])
GL.glEnd()

And that's it! Setting up the proper textures and materials is rather complex and is def.

hey again i found a Starcraft 2 Barracks Model enjoy:

Okay so all know i have just found the full name of the file type M3.

Its named: MDX3 (.m3) And It's the latest version of the MDX format, which has been used since Warcraft III.

The goal of this project is to document the format, along with developing code to read/write/edit these files.

Blizzard is using 3ds Max with an importer/exporter plugin, so making an importer/exporter for the format should be fairly possible as soon it's documented.

me ?? nah i dont

hmm didnt really wanted to atm waiting for the real game to come

and your render is done just so you know

Looks like sweet models. I'll see if I get into SC2 when the release comes