Help me vet this MDL importer.

[Holy_Diver]

Ah, I've found the meaning of all the packets. It turns out they are identical to the PSOne HMD primitive packets. I just didn't realize it because they are not ordered by their code numbers in the documentation I have (probably the order in the manual makes more sense if you know how the codes are derived)

I also understand the frame buffer now. Assuming Som follows the same rules you're limited to a 256x256 texture (what we already know) but also a single MDL file can only have 8 such textures. On the PSOne a great deal of the framebuffer is taken up by the screen but I'm assuming Som is not limited by that requirement.

You could have more than 8 smaller textures I suppose as long as they can be crammed into the frame buffer space without overlapping. If you use the indexed modes you can maybe have 512x512. Or 1024x1024 if you can settle 16 colours (and Som actually supports that mode) ...EDITED: Scratch that. I'm not sure that would work because I don't think you could map the 8bit texture coordinates beyond 256x256. The PSOne might have some way of scaling that but I doubt Som would have gone that far unless one of the models required it.

Still there are a ton of packets and I have a feeling only the ones actually used by Som files are supported by Som though it might not hurt to try others out some day. I think I have most of them but there might be others and I won't add any until we see them.

I added black texel (texture pixel -- let's be technical) knockout but Assimp totally shit itself as soon as one transparent texel was tossed into the mix. Not sure why that is (looking into it) but I will leave it disabled for now.



PS: I want to implement the framebuffer logic tomorrow before uploading a new importer demo.

[Holy_Diver]

Correction: the packets are not identical to HMD's but they're close enough I can easily deduce the meaning of the embedded flags. I knew there was a reason I'd already dismissed this possibility.

Correction: Som seems to use an older "TIM Bank" model of the PSOne frame buffer. This means the addressable number of 256x256 textures in a MDL file is probably 4.

[Holy_Diver]

Here (https://anon.swordofmoonlight.com/holy/S..._debug.exe) is a new version. I think this will be the last until I have some animations going.

I worked out the frame buffer mapping afaik. The files don't really seem consistent. I don't think the TIMs are limited to just the four "TIM Banks" I've seen ones which are not. But basically if a mapping to the framebuffer can't be made (a texture isn't where it should be) the first texture in the file seems to be used by default. This happens really fairly often. There aren't that many files with more than one texture and none with more than two afaik. Since there is no x2mdl program there's no way to know anything beyond what's in the mdl files themselves. We can test the limits of this sometime down the road I reckon.

I've also noticed enough of the TIMs have irregular coordinates in the frame buffer. Usually like they start on Y=1 instead of Y=0. If Som interprets this literally (or fails to -- if it was important to the modelers) it might explain the seams in the models. I will have to look into that further.


PS: If I get some of the transparency stuff working efficiently I will upload that / let you know. Assimp's transparency model is present overly conservative / probably broken. So it's more of a prob of leaning on Assimp's principal authors.

[Holy_Diver]

Btw, I don't think the textures are yet mapped correctly with regard to repeating (which I'm not sure if any of the MDL files take advantage of)

I've observed with Objedit at least you can have a texture repeat across a single face. The only limitation is you can only repeat up to 256 texels so you cannot repeat a 256x256 texture afaik. So if your texture is 16x16 in other words it can repeat 16 times. If for instance the field of grass object is not already setup that way, it should be. Though I'm speaking for MDL and the grass may be MDO (which I don't know anything about) but MDL grass could be made.

So for grass you could have a 16x16 texture representing one plane of the grass which could be repeated across a single quadrangle polygon 16 times for 16 tufts of grass (on one plane) ...then you'd want one such quadrangle for each row, and of course the more planes the betters (which would crisscross across one another)

I would not be at all surprised if the grass is already setup that way.

[Holy_Diver]

I'm uploading a new version of the exe. It should be done by the time I finish typing this.

There was a bug keeping the wooden treasure chest from importing and probably a number of other models. Frankly I can't comprehend how that file ever opened before this fix but I know it did.


Anyway I also noticed the keyhole on the treasure chest is just a sliver where if you look at the texture it is clearly not intended to be. The importer displays same as Objedit but I'm convinced this is not how the artists originally intended things to be. What ever is going on here would probably account for the seams in the models also. I've noticed the texture on the side of the treasure chest appears poorly mapped as well.

I'm going to have to fire up a game eventually and see if these artifacts show up in play or not. But I think it's safe to file this into the bug dept. I'm not sure doctoring the textures is the best way to try to address this.

[Holy_Diver]

Yeah I'm seeing this in game also. I think if we can get to the bottom of this the floor/ceiling tiles will line up properly also. Basically all the textures are off by a texel or two.

[Holy_Diver]

I tried a number of different scenarios and was able to remove 90% of the seam issues. I think maybe the artists begun with a concept of texture borders which were popular before hardware became able to wrap texture coordinates. The reason borders were important is because when the texture is filtered on the edge there are no neighbor texels to filter on one side for the edge pixels without a border.

It's possible Som is trying to use a texture border interface which is no longer supported by the drivers or hardware... but truthfully I'm not really sure what is going on. 90% sounds good but I actually think the more practical longterm approach is to cleanup the original MDL files (do the MDOs have this prob?) as soon as that is doable. I reckon whoever cares enough about their pet project to see that the monsters etc are all top notch will be the first to take a crack at that.

Any kind of fix will probably break repeating textures (assuming they work in game) more or less so I don't want to do that.

That said I can still probably add a setting to Ex for an immediate overall improvement at some point.


EDITED: Btw, I don't recommend Photoshopping the textures. Really it's the texture mapping (uv components) that require adjusting.

[Holy_Diver]

I'm uploading a new viewer download with animation for npcs/monsters like skeletons added.

I don't know for sure how close the model is but it seems close. I'd have to compare to some in game stuff. The skeleton death animation goes haywire... so there is either something special going on there I haven't seen or the transformation ordering might be wrong even though it looks good for everything else. The present order is the logical one anyway.

Assimp doesn't yet have a layout for the soft animations though I think it's a priority. Assimp advertises the Quake 1 MDL format is complete, but it isn't actually for the same reason.

I could probably still work it out / cook up an exporter without Assimp but I think I will wait until that is up and running. It would make visual verification a lot easier (than loading models up in Som)


If anyone is eager to do something with this. We should probably pick an suitable input file format (preferably already in the Assimp portfolio) and start by making a clock or something so I can get a visual read on the rotation metric. Timing is also something I don't understand. I'm guessing it's specified in the prf files. The .cp files I have a feeling are more or less just precomputed versions of the animation data. For some files like the treasure chests the .cp files are not actually used it seems. I'm not sure why. It might be a prf setting.

https://anon.swordofmoonlight.com/holy/S..._debug.exe


EDITED: Here are some animation IDs that will be covered in the next upload (whenever that is)

Code:

            if(p->id<2)
            {
                switch(p->id)
                {
                case 0: pAnim->mName = "Idle (default)"; break;
                case 1: pAnim->mName = "Walking (#1)"; break;
                }
            }
            else if(in->num_anims<5) //! guessing object
            {
                switch(p->id)
                {
                case 4: pAnim->mName = "Opening (#4)"; break;
                case 5: pAnim->mName = "Closing (#5)"; break;
                }
            }
            else if(in->num_anims<10) //! guessing enemy
            {
                switch(p->id)
                {
                case 4:  pAnim->mName = "Dying (#4)";      break;                
                case 6:  pAnim->mName = "Evading (#6)";    break;
                case 10: pAnim->mName = "Attack A (#10)";  break;
                case 11: pAnim->mName = "Attack B (#11)";  break;
                case 12: pAnim->mName = "Attack C (#12)";  break;
                case 13: pAnim->mName = "Attack D (#13)";  break;
                case 16: pAnim->mName = "Defending (#16)"; break;
                case 20: pAnim->mName = "Hitting (#20)";   break;
                }            
            }
            else switch(p->id) //! guessing npc
            {
            case 2:  pAnim->mName = "Hitting (#2)";          break;
            case 3:  pAnim->mName = "Dying (#3)";            break;
            case 4:  pAnim->mName = "To Left (#4)";          break;
            case 5:  pAnim->mName = "To Right (#5)";         break;
            case 6:  pAnim->mName = "To Face (#6)";          break;
            case 16: pAnim->mName = "Seated (#16)";          break;
            case 17: pAnim->mName = "Standing (#17)";        break;
            case 18: pAnim->mName = "Hitting Seated (#18)";  break;
            case 19: pAnim->mName = "Dying Seated (#19)";    break;
            case 20: pAnim->mName = "To Left Seated (#20)";  break;
            case 21: pAnim->mName = "To Right Seated (#21)"; break;
            case 22: pAnim->mName = "To Face Seated (#22)";  break;            
            }

[Holy_Diver]

As of now the viewer should handle the hard animation perfectly. There were a number of probs before including the rotation coordinate systems not being handled correctly. I think the only possible pitfall ATM may be the rotation angles, but it looks extremely close so it can only be slightly off if any.

My new theory on the .cp files is that they are related to the "control points" that are embedded in the models as little triangles. They also appear related to the animation so maybe it's just the control points being animated directly for easy access.

Since no one appears to be interested in setting up new monsters/npcs etc I will probably just move on to soft animation / the .cp file. The animation itself I think I've demonstrated (to myself) is not dependent upon the .cp file.

Files e105.mdl and e111.mdl are interesting. Getting the skeleton to die correctly and the axe armor to carry his axe right were really good test cases. The animation in this build is not all I'd like it to be. I've disabled interpolation (I have a feeling Som does not do interpolation) but the viewer runs at 60FPS and the Som animations run at about 30FPS I think... in fact I have a feeling Som never goes over 30FPS. The last animation frame goes back to the first. The viewer needs a lot of work in the animation dept and it's not really my code to muck around with.

https://anon.swordofmoonlight.com/holy/S..._debug.exe

[Holy_Diver]

Has anyone had trouble running this? I have a feeling you will because I just noticed the Assimp stuff is setup to use the DLL Msvcrt libraries. So I'm assuming no one has even independently run this yet...