This is not solved in, for example, darkplaces*: polygons with alpha transparency do not render properly against triangles from the same model behind those polys. You end up seeing the background behind the model rather than the rest of the model geometry as expected.


*At least last time I bothered checking... 

I solved this in DirectQ but it does involve sorting everything on a per-poly basis (rather than per-model, which would be standard for most). It's not hard but it is messy. You should probably also sort particles, water surfaces, sprites, MDLs (which I left sorted per-object rather than per-tri for performance reasons), and possibly other stuff into the same list.

(Aside: There is still a case where 3 or more triangles could partially overlap each other, and which no sorting algorithm could solve. That needs proper order-independent translucency, at which stage you've raised the hardware requirements for the engine so high that few enough people would be able to run it.)

What I did not do was allow for any TGA (or other type) with an alpha channel to have transparency. There are a lot of other BSP format-related problems with this, and ultimately Q1 BSP is just not set up for it. If nothing else, these polys would need to be treated the same as water for visibility determination/portalization, but still be able to generate clipping hulls, which I believe Q1BSP just does not allow at all.

You would need to make them "*" models which is one potential workaround. It would probably also make sense to have a texture naming convention for them, so that you're not slowing down load times by scanning every TGA for alpha (although some engines already do that anyway). 

"Any tga with an alpha channel gets rendered with transparency no matter what model or brush it's applied to?"

Yes, apparently thats what they all do.
DP has no problem sorting huge number of bmodels with alpha. But slapping the translucent tex on the entire ground caused some minor sorting issues.
http://imgur.com/a/Zto3F#5 

Very nice screenshots, pretty dark though. Good to see you're working on a town map - I don't have to feel bad for not finishing mine then. 

sv_main.c world sub models models > 999 can overflow string buffer.

szo fixed this in Quakespasm:

http://forums.inside3d.com/viewtopic.php?f=3&t=4458&start=15 

good catch, thanks for the info 

I noticed that Willem's White Room map hard locks fitzquake085 (have to ctrl+alt+del) but not fitzquake080. Happens for Negke also, I've got no idea why just giving a headsup :) 

http://celephais.net/board/view_thread.php?id=60277&start=93&end=97 

Ok its a known issue, I missed that! 

Fixed in quakespasm since version 0.85.4. See here for the fix, which is actually from quakeforge:
http://quakespasm.svn.sourceforge.net/viewvc/quakespasm?view=revision&revision=359 

FitzQuake 0.85 on Windows: Shambler's lightning attack animation not smoothed, even with r_lerpmodels and r_lerpmove enabled and r_nolerp_list cleared. Not a big deal, but still. 

That's intentional; Fitz doesn't interpolate when an entity goes into a muzzleflash frame. 

i think it might be something else (or the muzzle flash no lerping is linked to .owner in some way?) because checking the 106 progs, the muzzleflash is played on the shambler, not the lightning entity. 

Just a quick brainfart, thought I would post it to see if anyone else found it interesting. No idea if its even possible or easy to implement! :)

A worldspawn key for map specific colour grading / tinting.

Something like _colourmod R G B that will tint the screen image to the mappers preference. So if you have a slime/green themed map you could accentuate the greens/yellows slightly to give a customized final look. Together with fog some interesting visuals could be achieved.

/2 pence 

uhhhh what? you mean tinting the screen like a v_cshift command but automatically? 

I've never heard of this command :) I just tried it but im unsure what values it wants to do anything ;)

A suppose a simple explanation of what im on about would be that you could enter a theoretical "_colourmod" with values of .5 .5 .5 which would desaturate the entire image by removing half of every colour. 

mh is correct: the shambler attack has 7 frames in a row with EF_MUZZLEFLASH enabled. Fitzquake is set up to not lerp frames that have that effect, because usually it's accompanied by muzzle flare geo poking out of the front of a gun, which looks bad when lerped (i.e. on grunt, enforcer, and all player weapons.) Unfortunately it is an unnecessary feature for the shambler lighting attack.

If you don't like that feature, you can set r_lerpmodels to 2 instead of 1 and it should ignore those special exceptions. But, this will also disable the r_nolerp_list feature...

Ideally (note to RMQ team), there would be a way for quakec to tell the engine when lerping is acceptable (EF_NOLERP?), and even which frame to lerp to, and how long to spend lerping. This would only work with progs.dat written to provide that extra information, which is why all quake engines have to make various assumptions to try and make lerping look good. For example, Fitzquake uses .nextthink to guess how long to spend lerping, and EF_MUZZLEFLASH and r_nolerp_list to decide when it's a good idea to lerp. 

With DirectQ I decided that if a vertex moves 10 or more units from back to front between frames 0 and 1 then it's not interpolated. It works well with all current content, but of course something is going to break it at some point in time. That's something I accept for now. I didn't bother with enemy muzzleflashes.

For RMQ we're building new content and it can be made interpoaltion-friendly from the get-go. 

this is done per vertex?
like, if a zombie swings it's arm, the shoulder and upper arm are lerped, but the lower arm and hand (since they are moving fast) are not? 

And in some cases it works great.

It some cases, if you rapidly press pause and then unpause ... you see the most foobared looking thing imaginable.

I'm talking view weapons here. 

It's a little more complex than that.

First of all it's only done with the view model. The check is actually run inside of R_DrawViewModel so that's absolutely guaranteed: "if (!mod->delerped) {Mod_DelerpVertexes (mod); mod->delerped = true;}" or something like that. The viewmodel also runs a slightly different code-path, so even if somebody did decide to use zombie.mdl as a viewmodel (those wacky modders!) it's also guaranteed to not happen with regular zombies too.

Secondly, it only checks vertexes that move between frames 0 and 1 of the model (if the model has only 1 frame - and there are some - it doesn't bother). So no matter how much a vertex may move in any other frame doesn't matter and doesn't affect the result; it's only "if it was in this position in frame 0 and in that postion in frame 1" that counts.

Thirdly, it's only movement in the back-to-front direction that is measured. So apply aliashdr_t::scale and aliashdr_t::scale_origin to the positions in each trivertx_t, then check the difference between element[0] of each - over 10 indicates a positive result - this vertex was way at the back of the model in frame 0, in frame 1 it's way out at the front, so we don't want to interpolate it.

The result from this comparison carries through to other frames, and so far it's proven to be valid with all ID1, Rogue, Hipnotic, Zerstorer, Quoth, etc weapon models (it even worked perfectly with Hellsmash) - it successfully removes interpolation from the muzzleflash verts, and only from the muzzleflash verts.

I have an idea that a nicer implementation might be to weigh the blend factor depending on the distance between the current and previous verts for any pair of frames; that could be run on the GPU in a vertex shader, wouldn't need any special case handling, and it's something I may experiment with some day. 

oh ok, i didn't know if was only for view models.
sounds like you've got all the bases covered i guess; i've never looked at the engine code much, so i don't really get the specifics of it all. 

So that's why the lightning effect on the RMQ Cauteriser interpolates, even though that's not intended.

So with the proposed solution it'd just be a case of moving the lightning part of the mesh very far back in the 'miss' frames. 

Yup; just move it as far back as possible in frame 0.

I tried the vertex shader idea, and it works fairly well. Things are occasionally jerky during dying animations, but it's a reasonable enough general solution. I think I might save it up as a fallback if my current method ever breaks. 

Is it anyhow possible to smooth the movement of the lightning gun bolt (when you fire and sweep around with that weapon)?