the Quoth beigeknight

Is my least favorite part of Quoth, all bullshit damage ratios aside. WTF?! 

I assume red epaulets interfered with the strong red-equals-rockets color scheme they were going for, and they wanted him to look more like the hell knight. Does make him pretty bland.

OUM technosupervillains added. 

yes, lunaran is correct in that it was purely to make them match the hellknights more. 

I couldn't stand the chunky swimplayer, so I made a new one.
It's still in repair because of my experiences with the amphebian.
I'm a singleplayer, so purpose lies more in the dm scene,
but anyway it's a start . 

If you want your models to work in winquake, be careful where you put your seams! Models that have seam vertices on the rightmost column of pixels on the skin experience terrible corruption, with triangles that stretch to infinity at some angles, and random pixels on the skinmap. I've not looked for reasons in the code here, it's just experimental results.

I seem to have experienced some fortune in my models afflicted by this - all of them appear to not use the leftmost column on the skin and start their skin coordinates at 1. So I can apply the simple fix of translating all skin vertices left by one pixel. That however makes me worry that perhaps there's a bug in md3tomdl which means zero coordinates are never (or too rarely) generated... 

So, maybe not, now it's looking more like there's a bug in either qmdl or md3tomdl that creates mdl files winquake doesn't like. Saving with QME fixes whatever it is, the translation left by 1 unit was a red herring. More later... 

OK, so here's the actual deal. It does relate to onseam vertices. Winquake is picky about the flag in a way glquake isn't. You MUST use the value 32 to indicate a vertex is onseam. Setting this value to 1 works fine in glquake but glitches out in software. I'm guessing there's a mixture of code in winquake between

if(v.onseam) //checks for any non-zero value
and
if(v.onseam == 32) //checks for 32 only

So if you aren't careful you get half-onseam rendering, which is a big mess. Lesson learnt.
GLquake probably just uses the former test everywhere which explains how I could get away with being sloppy so far... 

just to be clear, while onseam is treated as a boolean, in order for it to work in winquake, it must be set to 32?

good to know. 

The two valid values for onseam are

0: Internal vertex
and
32: Onseam vertex

GLQuake (appears to) treat all non-zero values as Onseam, but WinQuake displays graphical glitches for models that use any other value.

I've narrowed the problem in my tools to helper.py in the python qmdl module. md3tomdl doesn't ever set onseam, because it uses the MD3 style skinmaps where separate vertices on the skin are separated on the 3d model as well. One of the new features in helper.py is stitching a classic front-back skinmap model back together if it's been through md3tomdl. It looks for pairs of vertices that could be merged to make a single onseam vertex. But when it does this, it set the value of onseam as boolean True, which got converted to 1 when the model was exported.

PS: The stitching back together trick is actually fairly robust. You can create a model from scratch and carefully lay out seams half a skin width apart to create classic-style skins from an md3. You can even construct otherwise impossible skin mappings, like a cylinder with a single seam that spans across the middle of the skin, although they are for the most part interesting only academically. 

cool, thanks for that bit of info! i changed the setOnSeam method in my model editor to just set 32 all the time. 

I guess I can safely say that I won't resume my tinkering with Quake models any time soon, so I'll just share the only thing that's somewhat finished.

https://drive.google.com/file/d/0B9DxOfPvG2G1Sk41OEpBYlhTZGM/edit?usp=sharing

Old shot:

http://i.imgur.com/R5G56tM.png

Animation is interpolation-friendly. 

very cool, kind of organic vibe to it. the model could also double as a lightning gun variant. 

I was going to ask for that model so i can look into why glquake is messing up the texture coord vs winquake :-) 

Awesome work Dwere :D 

of pixel shells (lid is optional extra) 

You know what'd be cool? If ammo could detect map types, that way you could have runic, medieval and base type boxes! :) 

You know what'd be cool? If ammo could detect map types, that way you could have runic, medieval and base type boxes! :) 

All it takes is a simple QC modification. 

that could easily be done. (keys already do it) 

I guess the next version of Quoth can add it as a feature then. ;) 

 

Some examples of the hellknight in paper, made with pepakura.
Now he will be my action figure ever!
Little hard to paint on the skin right.
1 2 3 

@Preach: I'm trying to create a model and it looks ok in darkplaces if I simply use the md3 file, but whenever I "compile" the mdl file from the md3 file it comes out all poly garbled, like the faces are pointing the wrong ways and small faces get stretched or combined and folded inwards on itself. I suspect it's the exporter that I'm using with blender because the skin works and the model is visible so I think md3tomdl is working fine.

Preach, what md3 exporter are you using? and what blender version? I have 2.71 and am using katsbits md3 exporter version 1.6.3 (for blender 2.63a from this page: http://www.katsbits.com/tools/ 

Maybe this might be useful: http://www.quakeunity.com/file=481
I use it when importing md3s exported from max, but you could try just importing the blender md3 and see if anything looks wrong then saving from that application before using preach's converter. 

I use GMAX and the md3 export which comes with that - by pop'n'fresh I think... If darkplaces loads the md3 fine then it's more likely a bug in md3tomdl, probably some edge case that the parser I wrote gets wrong. Can you e-mail me a copy of the file so I can take a look.