With the small changes we applied to v_electro.md3 and v_laser.md3 in master, their file size didn't change that much and we used Blender to re-export them.
Maybe different Blender or plugin versions? Or different options in the export plugin?
i use blender 2.79b and even with the md3 plugin legendguard sent me i cannot export from .blend, the size difference may be caused by me directly editing the models themselves. so what i could do is edit the blend files and post them here maybe?
@terencehill, the file size doesn't matter, what matters is how should look. It could be the original exportation (2013 ~ 2016 seems old, many changes happened) wasn't more optimized than the actual one. Also, Blender has optimization tools for the models like converting tris to quads (be careful with the UVs, it could break. Just select the polys/faces you're right to maintain the UVs) and remove doubles (there are models with useless vertices/faces or some could remain hidden).
Regarding animations (for weapons are h_* ones), I found ok player models with useless animation keyframes where the player isn't moving in that part, I removed them and their file size is better than before.
I could rescale them from mediasource, there's a good branch where there are some of these weapons, it isn't still merged on master. The polys and all visuals are exactly the same, the exportation could change the file size, but consider that as optimization, the memory capacity of the project could be favorable.
the file size doesn't matter, what matters is how should look.
Yes, obviously the model should look the same (or better) in game. But it should also work well in all other aspects that we can't easily see, for example does it have the same (or better) performance? Do shadows work correctly?
I could rescale them from mediasource, there's a good branch where there are some of these weapons, it isn't still merged on master. The polys and all visuals are exactly the same, the exportation could change the file size, but consider that as optimization, the memory capacity of the project could be favorable.
Yes, as an example can you try exporting the devastator model and post it here? And while at it scale it to 0.75x. I'd like to test it.
Relatedly it would be nice to have a "gun fov" cvar, something like warsow's cg_gun_fov, which allows players to compensate for the way the first person viewmodel extends closer to the xhair as fov is increased.
An easy way to scale all of them is to add a line like this.exteriorweaponentity.scale = 13/16; // try a smaller gun (DP rendering scale uses 1/16th accuracy)
after this.exteriorweaponentity.alpha = default_weapon_alpha; in void PutPlayerInServer(entity this)
it has to be done in SVQC since currently these are generic ENT_CLIENT_MODEL in CSQC.
But one scale does not fit all, and when looking closely its quite noticeable that the arm/hand and relative model positions need to change for each gun to suit the different stock lengths and grip types.
Sadly we don't seem to be above that kind of hackery, as this is from the Racer code: instance.scale = 0.5; // FIXME: this be hakkz, fix the models insted (scale body, add tag_viewport to the hudmodel).
@guitardood91 can you at least put in the beginning of your post a line stating that the screenshots you posted show the weapons you scaled and not the current ones?
Did you scale them all with the same factor? Please document the values you used or maybe just show screenshots where you compare current weapons to your edits. A table like this would be handy (I'm displaying the same image in this example):
I personally would scale many weapons to make them consistent but in order to avoid players complaining too much it'd be wise to scale only the bigger weapons, specifically vortex, rl and fireball by 15-20% as per musicgoat suggestion. What do you think?
Optionally we could resize the instrument-weapons too.
@terencehill What do you think about the scaled ones? If you look the player's left/right hand, it's noticeable,
I reduced the scale by 15%:
Devastator:
Vortex:
Fireball:
About Vortex and Fireball, these were exported to SMD and after used dpmodel to compile for DPM and MD3. The original ones were exported using dpmodel too, I discovered how they did. Originally, Devastator wasn't exported to SMD, it was exported to IQM using a plugin from Blender changing the extension to MD3; in my optimized version I exported to SMD, compiled with dpmodel and copying the MD3 one.
Bad news happened! Fireball model from mediasource and from your shared file have a problem in the middle of the polys, the mesh is pretty messed up, some 3d artist notices these details even in-game. I had to fix that modeling the middle of the polys, I had to remove all of them and apply Mirror modifier to unite the polys correctly and I had to redo the UVs, that has been a hard work. I wonder who modeled this and messed up the model polys where he shouldn't, wth with that modeler guy. He broke the mesh model.
i don't really agree with the vortex change. in first person (and with a default fov) you cannot see the screen. the MR to adjust screen color per player is then somewhat nullified. perhaps just reducing the x axis scale by ~20% is the better choice here?
Oops, that's the secondary effect of the exportation. I didn't know Vortex model uses old methodology as the introduction is saying, I hadn't looked about h_* one. I can return the scale how it was before.
Maybe those errors are caused by the import/export plugins? Make sure there's REALLY no alternative way to import/export the problematic weapon models without generating those errors.
Tip for testing weapons in game: if you replace a weapon in the filesystem, you can reload it instantly (without restarting the game or executing r_restart) while the player model is holding it with the command: modelprecache models/weapons/v_nex.md3
Maybe those errors are caused by the import/export plugins? Make sure there's REALLY no alternative way to import/export the problematic weapon models without generating those errors.