This guy will be thrilled to hear about a new knight model. 

Post some screens over there (and here :) 

Thanks, Preach! :beer:

I'm not going overboard with the knight - it uses the old skin, and doesn't go any farther than good Quake level of detail lest it look out of place, so he's still got one flat quad for a face, but, you know, at least he has an entire quad for his face now :)

Sock was disappointed I didn't give him a nose though. 

Sock was disappointed I didn't give him a nose though.
*facepalm* Lunaran knight model! 

The facepalm that flattened his nose? 

Whatever e-mail glitch there is between us operates both ways, it seems.

I've had a little bit more of a poke around with the knight model and some tools. I took a look at the binary output for the first two frames of attackb, and also ran the model through my python loader so I could inspect how the parsed data turned out. I can't see anything too weird going on with the attackb sequence though - it looks like it's just a length 10 animation sequence, with the first pose duplicated to make the sequence 11 frames long. The engine doesn't actually care what you call the frames, either in demos or live gameplay, it just references them by numbers, so the only important thing is getting them in exactly the same sequence as the original.

Since I can't find anything weird going on, I'm worried that I've misunderstood the problem. Is it possible you can send me some attempted models to take a look at, and see if I can spot what's happening with them? 

It turns out I'm just a dumb idiot.


(short version: I was testing the knight out of /lunsp2/, since that's where all my model export stuff was already pointed and I am lazy, and at some point years ago I must have seen the duplicate $frame in knight.qc and "fixed" it, because I am proactive. The odd behavior was just a mismatch between gameplay in lunsp2 and demos recorded in id1, and had nothing to do with the model.)

Thanks, Preach! 

I made a decision to plunge into the wonderful world of 3D modelling.

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

Looks like a cross between the ripper and the flak cannon from Unreal! :) 

Oh God, now I wanna do a Q1 UT mod x_x
Sweet model! 

Is it possible to create the Chasm monsters and Weapons in the Quake Engine? 

Thanks.

Speaking about Chasm, I think I ripped off its energy crossbow, though I didn't realise it at the time.

I'm having some problems with UVs, by the way. I'm using QuakeForge Blender plugin and it seems to shift around coordinates in a certain way. At first I thought that it was a format-related precision problem, but when I tried to move affected coordinates in the opposite directions before exporting, I got ideal UVs on output. 

http://lunaran.com/pics/lunsp2/knight2.gif

This stupid run attack, man.

The knight calls ai_charge_side on every frame of his run attack, which calls walkmove(20). That's 20 in units. Trying to animate this guy doing a full-strength baseball swing while somehow moving his legs in a way that covers 200 units in 10 frames without the feet sliding is ... challenging, especially because it has to properly transition into run1.

That's the second pass and it still could be better. First pass I tried four strides of 50u each, which was a good length, but with only 11 frames to move his feet to all those positions, his legs were teleporting between very disparate poses and it was breaking persistence of vision, so he just looked crazy-Flintstones-bongo-legs.

Two strides of 100u each is way too long, and he just barely doesn't look like a flying ballerina if I turn his hips all the way to the side and have him twist and push off the very toe, but at least it reads properly as an animation this way, especially from the front where you'll usually be seeing it.

Plus, anything's better than the original knight, who as you can see hardly shuffles his feet forward at all in this anim and skates the whole distance instead. Also for a frame or two his head almost comes off. Also his feet are actually about four units off the ground for the majority of the anim. and so on.

It's close, though. I need to add some blend shapes to the rig to puff out the knees and elbows when they bend deeply, since they collapse pretty badly at extremes, but at that point I might call it done.

I'm trying to gather relevant skins also. So far I have stock, the Quoth beigeknight, and those two weird skins from ARWOP that make him look like a superhero. Any other prominent mods have prominent knight skins? 

Yeah, under the constraints I think you've done a fine job with the animation, makes it into a proper lunge. Also props for fixing the texture map on the sword, it always bugs me how much detail is lost from the knight texture through misalignment.

For skins, did Operation Urth Magik have tech-knights with lightsabres in it? Or was that just the hell knight model? 

It had two if I remember rightly. 

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.