We cannot have forced player models in conjunction with non-ZYM format models, because animation is handled entirely different for them. You can try it out in current svn, animations look REALLY bad, wrong, and irritating if you are forcing models to a md3 one and players have zym, or vice versa.

So basically, a choice has to be made.

Models affected by this are:
angelyss.md3 (NSFW)
cow.md3 (stupid)
jaguar.md3 (simple)

Also, the ZYM model creation pipeline is AWFUL, which means by choosing to remove support for md3 and dpm, we'll be much less likely to get any new player model artists.

All other models would not get lost if we remove md3/dpm support for player models.

Another feature, if we add support forced player models, is a mode that only forces other models to yours if they do not come with Nexuiz (which basically means you'll no longer see anything NSFW).

The only way around this would be moving animation handling to CSQC, which won't happen anytime soon (as it'd basically require half of Nexuiz to be entirely rewritten, and nobody even knows how that CSQC stuff works anyway).

Add support for forced playermodels, remove support for other model formats than DPM, write a blender exporter for DPM.

So my understanding is:

1) With SMD / ZYM you have bones, but bones with no vertex weighting, so all vertices go with the bone they're assigned to as if it was a solid object. The format also doesn't support more advanced skeletal animation features like IK either, of course.

2) With MD3 you have no bones (not sure how you place weapon locations then?), but you can export vertex animations, which means you can use any vertex weights and other advanced animation techniques and export them as vertex animations. Also you can make nice animated caterpillar tracks without killing the CPU or GPU with a million bones.

So we can't get rid of either, both formats are so primitive in different areas that they are both needed to fill in some of each other's gaps.

Furthermore, there is a very real need to add support for a model format that doesn't suck, like something which supports bones with real vertex weighting, which would also eliminate the need for this discussion, but probably require some serious work to implement.

IMO, this is the weakest point of the Nexuiz/Darkplaces graphics engine and has helped lead to the weakest point in the game's graphics content- character models. We don't need parallax mapping support or what have you, we need support for this.

DPM fills the gap, but again is not supported for self-playing animations in DP. Only ZYM is. And for all other formats, handling animation playing AND player model forcing is near impossible (would need to throw away all of Nexuiz and starting from scratch).

I so want support for self-playing animations of other formats in DP, but LordHavoc is opposed to that. There is no technical reason why DP cannot support self-playing MD3 (using clientside handled animinfo file) or DPM (using either animinfo file, or matching by same frame name).

divVerent wrote:tl;dr

Just tell me please which one is better in long term?

divVerent wrote:DPM fills the gap, but again is not supported for self-playing animations in DP. Only ZYM is. And for all other formats, handling animation playing AND player model forcing is near impossible (would need to throw away all of Nexuiz and starting from scratch).

Is self-playing animation exactly what it sounds like, and therefor not real important for character model animations that are instead responses to player input?

I so want support for self-playing animations of other formats in DP, but LordHavoc is opposed to that. There is no technical reason why DP cannot support self-playing MD3 (using clientside handled animinfo file) or DPM (using either animinfo file, or matching by same frame name).

So why is he against it then?

Why not md5?

Self-playing: server sends "play animation 3", client plays it until server sends another command
Non-self-playing: server sends "play frame 20", then "play frame 21", then "play frame 22", ..., then "play frame 29", then "play frame 20"

Only ZYM behaves in the former way.

divVerent wrote:Only ZYM behaves in the former way.

Ok voted ZYM

BTW, I am just working on server-side animation handling, which will make this point moot, but all MD3 models need to be repacked with the animinfo file renamed to framegroups, and edited to specify which anims are looped. So existing MD3 models will still break.

divVerent wrote:Self-playing: server sends "play animation 3", client plays it until server sends another command

Non-self-playing: server sends "play frame 20", then "play frame 21", then "play frame 22", ..., then "play frame 29", then "play frame 20"

Only ZYM behaves in the former way.

So then self-playing is not important for character and vehicle model animations because those are all done client-side, right?

DPM fills the gap, but again is not supported for self-playing animations in DP.

Since it looks like things are going in favor of keeping the other formats, is there anyplace to find out the details about this DPM format? Like what features does it support, what exporter(s) are available for it, etc.

Again: character animations are NOT clientside, and the whole problem. We have
nobody able to move them clientside.

n00b question: by "move them to clientside", do you mean engine or CSQC?