Help me vet this MDL importer.

#1
Here is the first steps towards breaking the MDL files free of Som's clutches. It should open a great number of MDL files though I'm aware of a few I plan on adding support for but I thought I'd go ahead and toss this out there before taking a look at those.

I want to ask everyone to try to open as many MDLs as you can with it and let me know which ones don't work (there has to be at least a few) and more importantly anything in the importer that doesn't look identical to Som... I mean down to the last nitpicking detail.

The reason I need help is the MDL files have this packet encoding scheme and most files only use one to three of the kinds of primitive packets available (of which there are a good deal) so I have to run into a particular kind of packet before I can wrap my head around what it's doing.

I don't actually know what this build will do if it runs into an unrecognized packet code, but you will be able to tell.

If you find a file that just doesn't open report it and wait until I've fixed it before looking for more because I don't want you to test a bunch of files that all have the same problem.

This is actually a custom build of Assimpview. I've changed the name to Somimp_so_and_so just so it won't be able to take on a life of it's own and get confused for Assimpview. It's not Somimp either.

Before anyone spazzes out you can't actually use this for anything but it does represent an understanding of the format itself. Once we understand it 100% we can start converting other files into MDL files. I think all that is left to do is animation. But I have a feeling that will prove a whole other ballgame...

EDITED: The new dl location: https://anon.swordofmoonlight.com/holy/S..._debug.exe
Reply

#2
The app file is having trouble uploading (6MBs) even though it's not above the attachment limit I think.

I will upload it to Todd's server later tonight. In the meantime here is a screenshot.


Attached Files Thumbnail(s)
   
Reply

#3
I can't seem to FTP this website anymore...
Reply

#4
I've noticed on my computer many of the models have gaping seams in their textures (evidence attached)

I don't know if these actually show up in a Som game but they are the same in the Objedit tool (see screenshot)


This could be an artifact of modern drivers. I think something like this would've caught my eye sooner if I saw it in game. So I'm not sure it shows up there. There might be a better way to map the MDL texture units than the obvious way.

Either way this could be fixed by doctoring the textures so that the negative space is removed or at least pushed back a couple pixels.

If someone could confirm if this pig monster has seams in game or not that would be helpful.


On a related not there are also a number of models with hard edges inadvertently mixed in with soft edges that just look wrong. Would not hurt to clean that up also. Lazy From' modelers.


PS: I have not uploaded a new download yet but I've fixed a bug that I did not realize I introduced while working on the tentacle boss (he has the first I did with two texture maps mingled throughout the triangles) so I recommend checking this out but maybe waiting until I can get a new version up before starting systematically testing files for us.


Attached Files Thumbnail(s)
   
Reply

#5
Top attachment updated Smokin
Reply

#6
This looks like really good stuff.

I will download it and run all the mdls I can find through it this week.

Well done.
- Todd DuFore (DMPDesign)
Site Founder
Reply

#7
There are some issues with transparency type stuff which I'm aware of/not gung ho to worry about atm. But anything else, and I mean anything I want to know about it / have on record. Also Assimp adds lighting "normals" if missing which is kind of the same deal (materials dept) so some models will be shaded when they are not with the Somtools.

I want to go ahead and get cracking on animation. I thought it would be tough but I noticed in the Somtools the monsters (and probably treasure chests etc) strike a pose so that will give me something to use for visual verification.

I'm aware the Arm.mdl file has the wrong texture showing. I dunno what's up with that file or why it has two textures in the first place (which seem to be swapped position in the file wise -- the first texture is not or no longer used as far as I can tell) but anyway I may get to the bottom of that sense it's a very useful file for staring at the animation data because the number of vertices are low enough that their indices really stand out.

The Goblin file also seems to have two identical (this time) textures. I don't know if the faces dip into both or just one.

I gotta admit the quality and quantity of these monsters are really quite good.


EDITED: Make sure you enable Backface culling because a lot of the thin pieces of the models do show through the other side for whatever reason.
Reply

#8
(2010-04-13, 01:25 PM)dmpdesign link Wrote: This looks like really good stuff.

I will download it and run all the mdls I can find through it this week.

Well done.

I think the success rate will be pretty high if not 100% (it turns out there aren't as many mdl files as I'd imagined -- no items etc) but please pay close attention to details. Try to compare to the Somtools if there appears to be a defect. With Eneedit I've notice for many of the mdl files like e005.mdl corresponds to 105.prf (just add 100.)
Reply

#9
As for models with misaligned textures, almost all of them have that problem. ‎  John had begun fixing many but I am not aware of him ever posting the fixed files. ‎  Doubt we will ever see the work he had begun on them.

Your ftp was changed (temporarily) to the dl.swordofmoonlight.com site. ‎  I will get it fixed.
- Todd DuFore (DMPDesign)
Site Founder
Reply

#10
It turns out I left out some parenthesis in the code that bungled the face to texture assignment. So in the current build the final tentacle boss won't have the second texture with all the features in it. So I will have to get another build up some time soon I reckon.

I also put back some primitives which I was misinterpreting. They now show up as little control triangles which seem to define things like center, ground level, and damage dealing elements. You can see these in Objedit for hte final boss because it uses a different primitive for some reason. It's possible even he might be buggy because the wrong primitive is used. He appears to have damage dealers at the end of each tentacle. I thought these were used to control his tentacle animation at first but I think now they are damage dealers.

Anyway I will put those back so you all can form your opinions. They have colours assigned to them also so I will add that. The colours might even encode encode fine grain information. Or I noticed one triangle on maybe stone face was like all red and the next was red with just one point of blue I think... so maybe the modeler just didn't set the colour right is all. I don't know if the colours are just for debug visuals or if they are interpreted by Som.

Also I just did an experiment with the ARM.MDL file. I swapped the framebuffer coordinates of the two textures and sure enough the other texture was used. So Som must simulate the PSOne frame buffer. That could mean there's a chance two textures could be placed side by side in the framebuffer so that triangles could seamlessly lie over the boundaries. It depends on how the textures are passed to DirectX. The simulated frame buffer might just be a software thing to make Froms' old PSOne models/tools compatible workflow wise.

So I might try to work that into the next build.


I think I have a grasp of what is going on in the animation dept but it's still a lot of theory mostly based on PSOne docs and observations. Hopefully the elaborate PSOne framework is not too exotic to faithfully translate into more contemporary/less hardware centric animation paradigms. I might say something at some point regarding animation, but I won't bog down this thread with it.
Reply





Users browsing this thread:
4 Guest(s)