gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > MD2 loading

#57400 - omaremad - Sat Oct 15, 2005 3:59 pm

I understand that there are many md2 loaders out there however none have been "opensource".

So i decided to write my own one.

It works fine on my pc and i wrote it so i draw in triangles only not triangle strips etc.. so its pretty much ds compatible.

However i have no idea how the filesystem works on the ds.

To load the md2 i need commands like fopen and fseek but this cant be done on the ds. So can the people that made the md2 loaders please help or release their code.

#57401 - El Hobito - Sat Oct 15, 2005 4:18 pm

which method do you intend on loading the md2 in with? there are many tutorials around that deal with gbfs which is a filesystem for use with flashcarts. There is also the ability to load files from a cf card via the gbamp and m3 adpater. I believe they work in exact same fashion as the standard fopen but you can have a look at the source which explains it for you nicely

edit: here are some filesystem tuts for you on gbfs

#57406 - omaremad - Sat Oct 15, 2005 5:04 pm

I already tried that

#57410 - tepples - Sat Oct 15, 2005 6:03 pm

"I already tried that" doesn't help unless you tell what error message you got.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#57416 - El Hobito - Sat Oct 15, 2005 6:32 pm

Quote:
There are other gbfs functions that can be used and they're all explained in the readme file included in the gbfs distribution.

if your not willing to explain the prob then we cant help you

#57417 - Ethos - Sat Oct 15, 2005 6:35 pm

Seems he didn't look too hard.

http://www.neoflash.com/forum/index.php/topic,603.0.html

its there if you are logged in...

Also do you know anything about 3D on DS?

Triangle Strips are there...but no fans....using triangles is extremely inefficient!
_________________
Ethos' Homepage (Demos/NDS 3D Tutorial)

#57434 - omaremad - Sat Oct 15, 2005 8:56 pm

Even though my question sounds stupid i did my reasearch.

The reason im not using triangle fans is that they require opengl commands to be stored in the md2 files(this is fine with official files) BUT the blender md2 exporter doesnt export the commands so i have to use triangles since there is no information in the file to tell the loader which type of triangle to use.

No2 i did see your loader before (i said that in my first post) all i want is either to write my own one or some would share their SOURCECODE with us or explain how they did it

#57585 - Ethos - Mon Oct 17, 2005 4:03 am

omaremad wrote:

No2 i did see your loader before (i said that in my first post) all i want is either to write my own one or some would share their SOURCECODE with us or explain how they did it


Hmm...did you look?? the source is there...duh!!

I like how you cap sourcecode...making it seem as if I don't understand...

Here is one for you...LOOK (Notice how the two OO's look like eyes? Use 'em)
_________________
Ethos' Homepage (Demos/NDS 3D Tutorial)

#57632 - omaremad - Mon Oct 17, 2005 1:38 pm

sorry if i sounded aggressive but i cant really see the link

#57658 - Ethos - Mon Oct 17, 2005 5:49 pm

Well the one i posted is a direct gl command one anyways (I did make another but can't find it).

But this link should help:

www.gametutorials.com/Tutorials/OpenGL/OpenGL_Pg4.htm

Look down for the MD2 loader...it should be an easy port (no unsupported GL commands)
_________________
Ethos' Homepage (Demos/NDS 3D Tutorial)

#57674 - omaremad - Mon Oct 17, 2005 7:06 pm

Once again thnx but i already made a loader for pc without gl commands

the problem is i cant get fopen and fseek to work on the ds so can you please tell me how or give me a direct link to the source

#57733 - dovoto - Tue Oct 18, 2005 1:15 am

put md2 in data dir

#include <myCoolDude_md2.h>

void loadmd2(u8* file, myObjStruct obj)
{
..blah blah some init

//fseak
possition = triangle_offset;

//fread
memcpy(&file[possition], obj->triangles, sizeoftriangles);

//or just: obj->triangles = &file[possition];

file io is much more cumbersum than treating the md2 like an array
...
blah blah

}
_________________
www.drunkencoders.com

#57743 - omaremad - Tue Oct 18, 2005 2:38 am

Thank you just what i needed

#57773 - discoloda - Tue Oct 18, 2005 10:05 am

I was wondering, with quake2 recently open source. why didnt you try that? some new engines can convert the models to pure triangles witch is indeed faster in some cases. im new to DS development but i think it should be given some tests about raw triangles vrs triangle strips. also it is posible to convert triangle fans to triangle fans by using degenerate triangles (a poly with no surface area)

one of the main reasons triangles are faster is because if you can draw from an array directly it doesnt take much to have one array for all of the vertexs and one array for all the elements. just call glDrawElements with that. for more complex models (like the ones in quake2) you would need to call DrawElements many times wich is slower. many calls to gl is bad. that is of course the case with computers but i will look into the DS opengl when i get to that point

#57775 - omaremad - Tue Oct 18, 2005 12:22 pm

actually md2 are nicer processing wise on the ds rather than skeleteal animation since all md2s are vertex listswhich u could use linear interpolation to move around an animate while bone animations required heavy bone weight calculations etc...

the md2 loader does do a lot of opengl commands this is how it works

get tris of current frame
get tris of next frame

do interpolate(on the cpu not gpu since the tris are just structures containg 3 vertices each with 3 vectors)

pass the final positions to opengl

#57847 - tepples - Tue Oct 18, 2005 9:40 pm

omaremad wrote:
actually md2 are nicer processing wise on the ds rather than skeleteal animation

Even in 4 MB of RAM? How many .md2 files are you planning on keeping loaded at once?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#57857 - discoloda - Tue Oct 18, 2005 10:27 pm

that is true, MD2 models (and other vertex warping fromats) take up more ram then ones with bones, but to make it fast you would need to think of a way to limit the calculations per frame. one vertex requires 9 multiplys and 9 adds. each bone that is a child of one bone requires 16 multiplys and 12 adds.

there are many ways todo this such as ony calculate once per second (choppy animation) or do some additional preproccessing, like a mix of bone and vertex warping (every x seconds pass out two version of the same model, 1 is the current frame the 2nd is the next frame then vertex warp those later)

#57968 - omaremad - Wed Oct 19, 2005 5:51 pm

Yeah i agree

All im loading is just 1 md2 which is kept in the memory
I perform the interpolation from the master data and pass the result to the opengl.

for diffrent looks i just add a diffrent texture.

Have a look at golden eye all the enemies are the same mesh but diffrent textures.

i was doing tests comparing sizes of .X and md2 models (same model)

the x file was 890kB and the md2 was 454kb LOL
but x files are badly compressed any way.

i have started work on my 3d engine for the ds i got collision detection and response working a small camera and stuff but the DEVKITARM16 has some really bad inpt suppourt cant get touch screen or keys to work on ideas

#57971 - dovoto - Wed Oct 19, 2005 6:16 pm

But you can get 3D to work on ideas? If so it has come a ways since last i used it.


And boned structs are not necessarily bad on the DS as it has hardware transform; ram and vertex limits are more pressing than cpu power most times. (Metroid uses a boned structure for its models i believe).
_________________
www.drunkencoders.com

#57976 - omaremad - Wed Oct 19, 2005 7:07 pm

I doesnt matter since the md2 was smaller in size than the .x(skeletal)

btw i only draw the current frame vertices

yeah 3d worked on ideas but input doesnt work so im now working using devkitarm r15 everything is fine now

#57977 - omaremad - Wed Oct 19, 2005 7:12 pm

opps

Btw you still have to do the bone calculations on the cpu Hardware transform means that the hardware calculates the transformation of the vertices but you still have to do stuff on the cpu to tell the vertices where to go.

Here is a question to every one . what up withe the vertex limits cant you just push it harder and get slower speeds. I mean factor 5 said the gc can do upto 15m polygons /s while nintendo said 6-12m polygons/s

and what about textured polygons they require more power so would we be allowed to draw less polygons

its so confusing!!

btw
the loadmatrix4x4 function doesnt work!

one last thing can the Homebrew devkit blend vertex colours with textures ?
that the way they lightmapped most games on the n64 and the metroid demo too.

#57989 - dovoto - Wed Oct 19, 2005 9:12 pm

omaremad wrote:
opps

Btw you still have to do the bone calculations on the cpu Hardware transform means that the hardware calculates the transformation of the vertices but you still have to do stuff on the cpu to tell the vertices where to go.


Is it not just draw root: rotate/translate child draw child: rotate/translate child, draw child etc...?

The DS has a very openGL (ish) pipeline which allows you to specify your rotation and scale and these get applied to the verticies as you push them in. You do not need to manual rotate and scale the verticies.

Maybe i just dont understand how boned animation works (definatly possible).

omaremad wrote:

Here is a question to every one . what up withe the vertex limits cant you just push it harder and get slower speeds. I mean factor 5 said the gc can do upto 15m polygons /s while nintendo said 6-12m polygons/s

and what about textured polygons they require more power so would we be allowed to draw less polygons

its so confusing!!


DS does not render into a frame buffer (it does it per scan line, although you can direct this render into a framebuffer which is not quite the same thing) and has an internal vertex limit likely due to only being able to store so many verticies at once. This means it takes what ever verticies are loaded into video memory and renders line by line to the screen(or memory) and not poly by poly. This was how it was explained to me and it seems likely given the small amount of video memory the DS posseses.

If it were frame buffer you could just render polys till the scene was complete then move onto the next frame and pretty much ignore the refresh rate of the video hardware and get the quility vs speed trade-off you are looking for.

As far as I have been able to determin there is no effect on polygon performance due to texturing. Perhaps someone could confirm.

omaremad wrote:

btw
the loadmatrix4x4 function doesnt work!


hmm...on hardware? I will look at this.

omaremad wrote:

one last thing, can the Homebrew devkit blend vertex colours with textures ?
that the way they lightmapped most games on the n64 and the metroid demo too.


of course..it also has 4 hardware lights that can be used (directional only).
_________________
www.drunkencoders.com

#58003 - omaremad - Wed Oct 19, 2005 10:34 pm

thanks dovoto for the help


I have analysed the .x reader and milkshape for the irrlicht engine

it appears it depends on the format

so formats store the matrix of each joint for every frame so you could pass it immediatly to the hardware like you said using the load matrix before the required vertices(no cpu required)

while others are more complex

for smooth animation you would have to interpolate between the matrices which would require the cpu

Quote:

each bone that is a child of one bone requires 16 multiplys and 12 adds.


Thanks very much

i havent got hardware currently so maybe ideas isnt loading the matrix