I've started writing an MD2 Loader (used in quake2) as the basis of an upcoming tutorial.
It's coming along really nicely. It's written for masm and with atc oop support, which makes stuff like file io much cleaner.
So far it loads all the data from the MD2 file into structures allocated on demand, and as it does so, displays the names of the animation frames.
They have names which are followed by numbers which indicate a sequence, for example, Walk01 thru Walk40, and there's a bunch of them.
Next I have to convert the data I loaded into something more friendly since some of the data in an MD2 is stored in funky ways to save space.
After that, I can put together a delay-based frame renderer and make sure everything is cool before implementing linear interpolation between frames.
Once all that's done, all that remains is the wrap the model struct as an oop object class and I'm ready to write my tute.
http://homer.ultrano.com/Upload/MD2Animation.zip
It's coming along really nicely. It's written for masm and with atc oop support, which makes stuff like file io much cleaner.
So far it loads all the data from the MD2 file into structures allocated on demand, and as it does so, displays the names of the animation frames.
They have names which are followed by numbers which indicate a sequence, for example, Walk01 thru Walk40, and there's a bunch of them.
Next I have to convert the data I loaded into something more friendly since some of the data in an MD2 is stored in funky ways to save space.
After that, I can put together a delay-based frame renderer and make sure everything is cool before implementing linear interpolation between frames.
Once all that's done, all that remains is the wrap the model struct as an oop object class and I'm ready to write my tute.
http://homer.ultrano.com/Upload/MD2Animation.zip
Nice one, but you should have used VKDebug in it - or anything else , other than msgbox - after the 4th msgbox the loader has already proven it gets the offsets alright - but clicking OK or holding Enter to get rid of them caused 10 instances of the loader to run on the university machine I ran it on :lol: . For me it's a shame .md2 stores vertex normals instead of face normals , I don't want gourad/phong shading in my software engine - so I'll have to make my own format again :lol: - for animated 3D. I'm looking at md3 these days since gmax exports it ;)
Btw, here's something that looks a lot like the game I want to make in x86 asm this summer:
http://www.mossjp.co.jp/raiden/raiden.htm
There are movies for each level too(5MB 320x240 each) : http://www.mossjp.co.jp/raiden/l_b_1.html
:)
The technology used there is what I'm currently concentrating on in the 3D gamedev world ^^"
Btw, here's something that looks a lot like the game I want to make in x86 asm this summer:
http://www.mossjp.co.jp/raiden/raiden.htm
There are movies for each level too(5MB 320x240 each) : http://www.mossjp.co.jp/raiden/l_b_1.html
:)
The technology used there is what I'm currently concentrating on in the 3D gamedev world ^^"
I do intend to go to MD3 and beyond, but for several reasons I want to write a nice and solid MD2 demo.
I want to keep the code simple and readable for a tutorial, and I want to show up any potential problems that might arise in more complex code.
The transition from MD2 to MD3 can be made without much pain, but is even easier with hindsight and a fistful of proven code.
Ultrano: Ah yes, I remember this one :)
I want to keep the code simple and readable for a tutorial, and I want to show up any potential problems that might arise in more complex code.
The transition from MD2 to MD3 can be made without much pain, but is even easier with hindsight and a fistful of proven code.
Ultrano: Ah yes, I remember this one :)
I've added the code for converting the raw data from the MD2 file into more friendly data structures, parsing the animation frames and enlisting the start and end frames of each named animation, etc.
Reuploaded to the same URL as previously.
Reuploaded to the same URL as previously.
Uhm does it save to a file, and if yes - what is its name? I can't see such a file though I expected it :| . And with that UPX packing, I can't see the (dis)asm :sad:
At the moment, I don't save the data to a custom file format - I am not loading it into my special optimising arrays, so I'm not bothering with a custom format to duplicate MD2.
The legal aspect: ID Games don't mind what we do with their file format, provided we use our own code to do it.
I'm still using MessageBox (sorry! I'll change soon).
I'm currently adding the code for calculating the current frame in "animation time" and also code for rendering the model with linear interpolation applied to the vertices in software.
I've recently come across notes about a little-used section of MD2 files which is called GLCommands. It describes the model geometry in terms of trianglestrips and fans, and can be used to render more quickly if the MD2 file contains this section.
I'll get back to that one later.
I implemented code to test the current frame calculation over time and its working.
Guess I'll have to put the OpenGL and Windows code back in soon so I can test the Render stuff out :) Not far away then :)
Ultrano - Sorry about the upx, I've added it to my BLDALL.BAT since I use it a lot.
You can use upx to decompress the executable if you like, and I'll happily ftp the source on request.
The legal aspect: ID Games don't mind what we do with their file format, provided we use our own code to do it.
I'm still using MessageBox (sorry! I'll change soon).
I'm currently adding the code for calculating the current frame in "animation time" and also code for rendering the model with linear interpolation applied to the vertices in software.
I've recently come across notes about a little-used section of MD2 files which is called GLCommands. It describes the model geometry in terms of trianglestrips and fans, and can be used to render more quickly if the MD2 file contains this section.
I'll get back to that one later.
I implemented code to test the current frame calculation over time and its working.
Guess I'll have to put the OpenGL and Windows code back in soon so I can test the Render stuff out :) Not far away then :)
Ultrano - Sorry about the upx, I've added it to my BLDALL.BAT since I use it a lot.
You can use upx to decompress the executable if you like, and I'll happily ftp the source on request.
exe packing - foo! ;)
Yes, please ftp the source :)
Ultrano - I've uploaded source as MD2Animation.zip in my ftp root.
If I missed any files, let me know.
Most of the files in the OOP folder are not used in this project, I just included the whole lot regardless.
The current version is still buggy, but happy days, most of the messageboxes are gone, and a logfile is employed. However, due to there being debug lines in the Render/Animate procs, the logfile will grow very large, very fast... don't leave the app rendering for long !!
Currently I can't see anything being rendered :(
I am yet to investigate the problem, it could be as simple as my camera view not pointing at the model. According to the logfile, the animation frames are being rendered correctly and incrementing over time correctly...
If I missed any files, let me know.
Most of the files in the OOP folder are not used in this project, I just included the whole lot regardless.
The current version is still buggy, but happy days, most of the messageboxes are gone, and a logfile is employed. However, due to there being debug lines in the Render/Animate procs, the logfile will grow very large, very fast... don't leave the app rendering for long !!
Currently I can't see anything being rendered :(
I am yet to investigate the problem, it could be as simple as my camera view not pointing at the model. According to the logfile, the animation frames are being rendered correctly and incrementing over time correctly...
I found and fixed one problem in CLoadMD2 class today.
The tMd2AliasTriangle structure was using word-sized vertex indices.
They should be BYTE indicies, and the ConvertDataStructures method should reference them as such, instead of Words.
The tMd2AliasTriangle structure was using word-sized vertex indices.
They should be BYTE indicies, and the ConvertDataStructures method should reference them as such, instead of Words.
After I run it in window mode, the window just stays black until I mouse-click on it. After the click I just see random lines at around 100fps flick out from the center to infinity, clicking again hides them. Pressing ESC, and I get a GPF: the EIP is 0x00000000 .. you've pushed somewhere too much I guess. The last line of the 40MB-200MB log is:
Returned from MainLoop procedure : April, Wednesday 06 2005 - 03:32:26 PM<190767338>
Could by any chance these problems be because of the logging? The logging seems too detail to me - in similar cases I just log the first one or two iterations only :)
Returned from MainLoop procedure : April, Wednesday 06 2005 - 03:32:26 PM<190767338>
Could by any chance these problems be because of the logging? The logging seems too detail to me - in similar cases I just log the first one or two iterations only :)
My logging macros are not totally register-safe, but they don't mess up the Stack.
The crash on shutdown is during the Cleanup phase, I'm releasing a resource somewhere twice, it's in the Animations resources since that's what's been added recently.
The logging is well and truly overkill, and should certainly take a minimalist approach within the render loop.
At first I was crashing during rendering , inside the AnimateModel proc.
I added some debug lines to it and got it to run without crashing, but still couldn't see anything onscreen so I went a little crazy there, adding more and more debug detail, trying to spot the issue...
One major issue I discovered within the CLoadMD2 class in the tMd2AliasTriangle struct and in the ConvertDataStructures method, I mentioned it in a previous post, the change is small and ineffctual - I still can't see my model.
This source is a straightforward translation of a proven C++ source.
The crash on shutdown is during the Cleanup phase, I'm releasing a resource somewhere twice, it's in the Animations resources since that's what's been added recently.
The logging is well and truly overkill, and should certainly take a minimalist approach within the render loop.
At first I was crashing during rendering , inside the AnimateModel proc.
I added some debug lines to it and got it to run without crashing, but still couldn't see anything onscreen so I went a little crazy there, adding more and more debug detail, trying to spot the issue...
One major issue I discovered within the CLoadMD2 class in the tMd2AliasTriangle struct and in the ConvertDataStructures method, I mentioned it in a previous post, the change is small and ineffctual - I still can't see my model.
This source is a straightforward translation of a proven C++ source.
Hello dudes
I encoutered the same thing some time ago with Quake models, nothing on the screen.
If I'm not mistaken the format of the texture and vertex data is not in floating point format but in 16 bit short
Vertex data ->? change short to float and divide by 64 (keep it in a normal range)
Texture data -> change short to float and divide by 256 (so texturecoords are between 0.0 and 1.0)
Greetings Siekmanski
I encoutered the same thing some time ago with Quake models, nothing on the screen.
If I'm not mistaken the format of the texture and vertex data is not in floating point format but in 16 bit short
Vertex data ->? change short to float and divide by 64 (keep it in a normal range)
Texture data -> change short to float and divide by 256 (so texturecoords are between 0.0 and 1.0)
Greetings Siekmanski
He does that already:
But shouldn't
fdiv .CLoadMD2.m_Header.skinWidth
be
fidiv .CLoadMD2.m_Header.skinWidth
?
(from file CLoadMD2_ClassDef.inc)
.while eax < .t3DObject.numTexVertex
; currentFrame.pTexVerts.x = m_pTexCoords.u / float(m_Header.skinWidth);
; currentFrame.pTexVerts.y = 1 - m_pTexCoords.v / float(m_Header.skinHeight);
mov edi,pcurrentFrame
mov edi,.t3DObject.pTexVerts
mov eax,sizeof Vec2
mul j
add edi,eax
mov esi,.CLoadMD2.m_pTexCoords
mov eax,sizeof tMd2TexCoord
mul j
add esi,eax
xor eax, eax
mov ax, .tMd2TexCoord.tu
mov dwtemp,eax
fild dwtemp
fdiv .CLoadMD2.m_Header.skinWidth
fstp .Vec2.U
But shouldn't
fdiv .CLoadMD2.m_Header.skinWidth
be
fidiv .CLoadMD2.m_Header.skinWidth
?
I think you are right about that, Ultrano.
I'm currently working on animated MD3 and messing with an MD3 exporter for Maya 4.0 , and learning the rules for modelling and animating with regards to the exporter. I'll implement that change in the MD2 code and re-upload it.
With regards to modelling for MD3:
Ultimately, I don't need to make Quake-ready models, I can make whatever models I like and animate them how I like.
The main thing that irks me is that I haven't come across any example of MD3 animation which really uses the bone information properly.
In Quake-style MD3 animation, the body consists of only several segments, being the legs, torso and head meshes, and they are strung together as a simple skeleton. Each mesh represents a Bone, and so each vertex is affected by only one Bone.
In real bone animation, the vertices are affected by more than one bone using a weighting system.
That means that the body can be totally seamless ie a single mesh, or alternatively that the "Seams" between the body segments can be hidden by "painting their weights" so the model looks nicer "when it bends".
The Quake-style MD3 is vertex animation of several objects, not real bone animation. The texture artists do a lot to hide the visual artifacts at seams.
I'm currently working on animated MD3 and messing with an MD3 exporter for Maya 4.0 , and learning the rules for modelling and animating with regards to the exporter. I'll implement that change in the MD2 code and re-upload it.
With regards to modelling for MD3:
Ultimately, I don't need to make Quake-ready models, I can make whatever models I like and animate them how I like.
The main thing that irks me is that I haven't come across any example of MD3 animation which really uses the bone information properly.
In Quake-style MD3 animation, the body consists of only several segments, being the legs, torso and head meshes, and they are strung together as a simple skeleton. Each mesh represents a Bone, and so each vertex is affected by only one Bone.
In real bone animation, the vertices are affected by more than one bone using a weighting system.
That means that the body can be totally seamless ie a single mesh, or alternatively that the "Seams" between the body segments can be hidden by "painting their weights" so the model looks nicer "when it bends".
The Quake-style MD3 is vertex animation of several objects, not real bone animation. The texture artists do a lot to hide the visual artifacts at seams.