MDR's designed for performance and the implementation is already mature, functional, and does what I want - the only issue are the models getting there.
I see no reason to go for IQM, even if Ioq3 had a fixed and patched up perfect IQM implementation - that still doesn't have tags or internal LODs, and that's more suited for projects that require full skeletal manipulation which OA is not one of.
I actually use IQM as an exchange format to MDR using Noesis and run a script like.....
A good bit of information there about OA3 that I wouldn't have thought to ask.
Very interesting! Thanks for the post
Also I'd never heard of MDR, so it was fun to get wind of that.
The polycount and stuff is a bit difficult to read on the model timeline. ctrl+ helped a bit, but not much.
the 2008 and 2012 models are the only ones who's face makes me believe they are alive. so those 2 are my favorites
I enjoy seeing the iterations, if you have any other models that have been around as long, and gone through as many starkly contrasting changes,
we'd love to see those as well.
Not enough characters have gone through that many iterations. Merman is more drastic though... Had a sex change, lost the flipper for legs, then lost the legs and then turned into a lamia.
MDR is developed for Star Trek Voyager Elite Force, a game developed on mostly late Pentium IIs @~450MHz range, so surely MDR is lean enough for that. The motivation for MDR were the memory savings and the allowing of a crapload of animation frames for believable single player drama, and using MD3 to do the same task would be unfeasible.
However, this doesn't mean OA will start supporting STVEF players. That would require cgame changes, to allow players2/, jpeg icons and worst of all, mp3 decoding for their sounds (MP3 is strongly undesirable). Supporting the MDR format doesn't mean these must be done.
OA doesn't need craploads of frames either - i'd be happy to just use MDR to exchange memory usage for CPU usage. I have been playing with extending animation though (torso running, jumping and aiming animations)
I should mention there was an unfortunate incident with the Community Map Pack with a contributing mapper sneaking in some non-Free textures. The pack has since been retracted (as much as it can be, since mirroring is contagious and some filehosts don't care *cough*Gamefront*cough*) and is in the process of a cleaner rerelease. It kills momentum and places new burdens on development, and versioning systems don't help either.
Stuff like that is why I have a very strict commit process for the base project (it only is allowed through one specific forum thread where I try to audit every contribution).
They're not nice concepts. I intended to scribble as many different identifiable shapes as I can to avoid confusion with each other while also attempting to make their funciton clear. Weapon size varies as well, since the railgun would be long etc
Guns that fire blue stuff are futurisitc and slightly mecha inspired. Guns that fire bullets seem more traditional and conventional but are still going to be abusrdly shaped so you can make out with them at a distance. There's no avoiding the shotgun and grenade launcher looking genericish. I'm still a bit lost on how to depict a functional rocket launcher that doesn't look like some RPG.
Also a note that I am still avoiding alpha channels and multiple textures. For example the scrolling shader on the railgun will be part of the same weapon texture as an all vertical strip being scrolled without light calculations, as a part of my aggressive optimization about texture switching.