dhewm
MD3 issues
I've been porting a Q3 based game over to Doom 3 and I've run into a couple of problems with directly using the MD3 models.
The biggest issue is that a missing MD3 model will (or at least can) cause the game and editor to crash on loading with no feedback.
The second issue is that MD3 models don't cast shadows in game, they seem to receive lighting correctly otherwise.
Can you post models (incl. textures, .def files and whatever else is required) that help reproducing the issues?
Here are some example maps, from my testing it's just the md3 extension that causes crashes, missing ase/lwo work fine as you would expect, and invalid (eg .whatever) file extensions are also handled properly.
https://drive.google.com/file/d/1qUAaA1Kz8G9fGpiqpiW4WN06DKP42YhV/view?usp=drive_link
Lighting issue appears to be common across all MD3 files from testing.
I also found that the statue MD3 model doesn't have any collision whereas the ASE does, I hadn't noticed this before.
I provided two different maps with missing MD3 models because there's a slight difference in behaviour between vanilla Doom3/fhDoom and dhewm3, dhewm3 will crash even if the MD3 file is in an invalid entity (misc_model), whereas vanilla/fhDoom it seems to only crash when the entity would actually load the model, although I only tested it with func_static.
test_models - lighting/collision problems
duel8_sample_ase/md3 - map copied from JA that will load as long as the models are renamed from .md3
test_missing_models - crash on loading example with func_static instead of misc_model for the slightly different behaviour in vanilla D3
Thanks for the testcases!
Regarding the collision (and maybe even lighting?) problems: Have you tried more options in the material?
Especially solid and/or collision seem worth a try.
(My theory why ASE and MD3 behave differently is that MD3 models are considered dynamic, while ASE are just one kind of model that's loaded into the generic idRenderModelStatic)
Regarding the crashes, I have a workaround (fix?) in #700 I wonder if only missing MD3 models cause these crashes, or if using MD5 (in the same way) would also crash or maybe spam the console if the file can't be found
I tested all the material keywords I could think of that could affect shadows and collision, as far as I could tell it didn't affect how the models were treated.
I think your theory about MD3 files is probably correct, MD5 files seem to lack collision when they're just used as models (the prop_ entities or when loaded into a func_animate), so I guess collision is only generated for them under specific circumstances - the lack of shadows is then probably just because the MD3 code wasn't finished/supported I guess?
I'm not really a programmer so this might be way harder than it sounds, since MD3 files are sort of treated both as static models and animated models, is it possible to detect if you've loaded a static/1 frame(?) MD3 and then have that handled by the same code as an ASE/LWO file rather than the code that handles animated models?
For the other stuff, missing .md5mesh files will spam the console with null joint but the map will load fine, func_statics won't load an MD5 model even when it exists but they can be loaded by func_animates (these also happily load ASE/LWO) to test behaviour differences.
I also tested your crash fix, the map will load in-game, but the editor still crashes when trying to load maps with missing MD3s or when setting a missing MD3 file as a model.
Cheers for looking into this.
I think your theory about MD3 files is probably correct, MD5 files seem to lack collision when they're just used as models (the prop_ entities or when loaded into a func_animate), so I guess collision is only generated for them under specific circumstances
Good to know, that's probably related then.. I guess in practice this doesn't matter much, you can just put a clip brush around them?
the lack of shadows is then probably just because the MD3 code wasn't finished/supported I guess?
Probably - so func_static with MD5 does throw shadows? Could you add a MD5 model to the testmap?
Something I noticed is that g_showEntityInfo shows a bounding box around the ASE model (as expected) but for the MD3 model it only shows a little grey box in the floor:
Those boxes are generated from the physics bounding boxes.
g_showViewEntities however shows full-sized bounding boxes around both models (those boxes are generated by the render model, in case of MD3 even for the current frame)
I also tested your crash fix, the map will load in-game, but the editor still crashes
Ok, I'll look into that
Probably - so func_static with MD5 does throw shadows? Could you add a MD5 model to the testmap?
They throw shadows, yes, it's via func_animate rather than func_static but they seem to be equivalent for static models.
Here's an updated map - https://drive.google.com/file/d/1SafMhnXMTirdUZTkkXwG2RW6j_rO0eYe/view?usp=sharing
The extra versions of the statue are just to show that func_animate isn't changing things.
I checked out the behaviour in other source ports too, fhDoom/TDM have basically the same behaviour, but RBDoom3BFG has working collisions and throws shadows, I don't know how similar the code base is, but I hope that helps.
Thanks!
I figured out why MD3 models don't cast shadows: no "sil edges" are generated (silhouette?).
Apparently in MD5 that happens in the deformInfos, I'm trying to replicate that for MD3 by calling R_BuildDeformInfo() for every surface and in idRenderModelMD3::InstantiateDynamicModel() using that deformInfo to set tri->silEdges and possibly more things.
I already have something that seems to work, but may have to duplicate more code from idMD5Mesh::UpdateSurface() for it to be reliable.
I think I found a better solution for the shadows.
I have ideas for an additional small optimization for non-animated MD3 files, but to test that I need an animated MD3 file to make sure I don't break that case. Do you happen to have a map with an animated MD3 model?
@FriskTheFallenHuman pointed at these two places in code for the collision issue (though as far as I can tell changing them isn't enough to make it solid): https://github.com/dhewm/dhewm3/blob/86152bb83728c82bd4f44d5382d8027b1578e1ed/neo/tools/compilers/dmap/tritjunction.cpp#L601 https://github.com/dhewm/dhewm3/blob/86152bb83728c82bd4f44d5382d8027b1578e1ed/neo/cm/CollisionModel_load.cpp#L2981
Either way I'm not sure I want to change that behavior, I guess it wouldn't make much sense (or work properly?) for animated MD3s? And TBH the main reason to use MD3 is for vertex animation, for static models the existing formats (ASE, LWO, MA) are probably better suited
I tried the latest test build out and everything seemed to be working well for my use cases, I wasn't actually planning on using the animated MD3 files because you have to jump through hoops to get the animation to work, but I do have them on hand so I did a quick test and it seemed to be fine.
Here's an updated pk4, the animated model is in the test_movingmodels map.
https://drive.google.com/file/d/1x724VuwN6FGhb9ivQSc5LVSrAAKaGx8N/view?usp=sharing
Regarding collision, as you said, it wouldn't make sense for animated models and for static models it can be easily done in editor or just by converting to an ASE if it's absolutely necessary, so I wouldn't really consider that an issue.
There is one other problem that I commonly run into, entities in the editor that use an MD3 model can't be selected via mouse click, you have to go into the entity list or select them some other way.
Thanks again for looking into this, it's obviously a bit of a niche issue.
Thank you very much! :)
Looks good so far, but I think I'll have to look more at it in the next days (and also check out the editor crash)
Fixed the crash in Radiant with missing models. Also fixed loading/displaying MD3 models in Radiant. I was hoping it would also fix the issue that they can't be selected, but unfortunately it didn't - no idea what causes this (might be related to MD3 models in func_static not having collision? That's just a wild guess though).