I finally saw the new models (got the MD5->MDL conversions).

Sadly, they went through the hacky route of disabling interpolations instead of creating the models in an interpolation-friendly way. Most of the new viewmodels have bad issues with muzzleflash interpolation, and the new enforcer also has a problematic muzzleflash.

Sorry, but disabling interpolations to "fix" model animations is an ugly hack.

The new grenade launcher's muzzleflash has poor texturing, each side of it looks completely different.

The kneel animation in the new knight model has the wrong height; the original model also has this problem, but they could have fixed that in the remade model.

Most of the new models are perfect, but these technical issues could have been fixed. 

We already fixed the muzzleflash for the RL in the AMQ which has the flash "travelling" through the model when firing. A mistake inherited from the md5, btw.

As for the Enforcer, Knight and GL, I have forwarded your feedback to osj over at QuakeOne. Fingers crossed! 

The rebuilt maps aren't z-fighting fixed. Instead the Kex engine is using polygon offset on brush models. That's massively disappointing, if understandable enough given competing demands on limited time. 

In the meantime, that QuakeOne patch for DOTM still has some flaws. Walking over corpses causes weird glitches (corpses are moving above you, so you basically walk underneath them, then they drop back down) and most ingame messages (e.g. for pickups) are still loca variables. 

Yeah, I found it still crashes QSS, so I have been using FTE for playing DOTM these days and am now at Episode 2. FTE supports dynamic lights so the fan shadow rotating effect in the hub map is preserved too. Don't know what other minor differences are there between FTE and KEX Engine, though. Loca variables are quite annoying for every slipgate tip, pick up tip, end message, etc. 

I haven't yet figured out how it's doing dynamic lights, but for animated lightstyles it's using something similar to the GPU lightmaps technique I've used for years.

My normal approach is to have 3 textures, one for each of the red, green and blue colour components. Each component in a texture represents one of the Quake styles. Each of the final colour channels can then be composed by a texture read and a dotproduct with the surface styles.

The Kex approach uses a 4-slice array texture, with each slice representing a style, and each texture being an RGBX colour. These are conditionally accumulated when styles are not 255.

I use array textures to allow me to only have a single lightmap texture that's bound only once at the start of the frame. Kex can't so that as it already uses array textures for styles, so it just seems to pack each style into a really large texture.

My approach uses less texture memory, and performance is absolutely level, irrespective of the complexity of the lightstyles on a surface. An optimization path exists for surfaces with only one style, but it adds some code complexity and I generally don't bother writing it up.

The Kex approach has potentially fewer texture accesses, as a tradeoff vs some shader branching and using more texture memory. Performance falls off for more complex styles.

Both approaches mean that lightmap textures are never updated at runtime, lightstyle interpolation can be done without affecting performance, lightmap accumulation runs at full internal precision, the maximum light value is never clamped, overbright lighting just comes out naturally, and the runtime codepaths are considerably simpler.

On balance I favour my own approach, for reasons of performance levelling and being more economical with texture memory, but I can understand why Nightdive did it their way. 

Does any of the custom engines have the realtime ambient occlusion that the KEX engine has? 

why would realtime AO be useful on a game like Quake? baked has much better quality 

I disabled AO but I guess some people seem to like it. It does add a shadow around the edges of some moving objects, which can help make doors, plats, etc seem more grounded in the world instead of "floating there", so there is that. But for me it's one of those things I've never really paid much heed to. 

As mh said, it helps with moving objects. See in the first demo, when the ceiling lowers to crush the player, the small shadows in the edges of the ceiling moves along the walls. It's a nice effect that I guess some people will demand custom engines to have.

However, I've noticed that in the Rogue mission pack the ambient occlusion is overdone, darkening wide angle corners that looks better without ambient occlusion. 

AO is also something that needs to be properly integrated into a post-processing pipeline, it's not a simple glEnable or anything like that. So what I'm saying is that doing it can be a very disruptive change to an engine, particularly if an engine doesn't already have a post-prcessing pipeline.

Engines like Unreal, Unity or even Kex already have all the groundwork in place for this; with Quake you have to do everything from scratch.

On the other hand you can do it wrong and crudely crowbar it in, which means that when people come looking for the next set of post-processing effects (and they always will) you'll end up with a mess to straighten out before you can do them. 

Silly question: I haven't looked into the MD5 code yet, but what would be the challenges to implement it in software-rendered engines? 

It should be very possible. Only the C code in r_alias.c would need additions, and that produces structures for use by the ASM code that are completely independent of any model format. The exception is R_AliasTransformAndProjectFinalVerts which consumes trivertx_t structs from the MDL, so that needs a C implementation for MD5s (unless you want to write an ASM version yourself).

It might be possible to combine this routine with the skeletal animation code as an optimization path, though.

The most important thing would be to get the bboxes absolutely tight. A hardware accelerated version is tolerant of loose bboxes, but a loose bbox in software means that you'll overflow the framebuffer pointer, write over and corrupt random memory, and probably crash. That was an issue when I wrote the software Quake interpolation code, but you might not even want to bother with interpolation. 

https://www.quaketastic.com/files/screen_shots/MD5_Software_Quake.pcx

This took me maybe half a day to do, and a good chunk of that time was spent trying to figure out a bug in skin texcoords.

I need to tidy up and comment the code a little, then I can release it publicly if anybody's interested. 

For anyone who's interested; you'll need to compile this yourself: https://github.com/mhQuake/MD5Stuff 

I'll try to implement it later.

As for the x86 ASM compatibility, it's better to simply disable the x86 code for character models because most of the speed gains provided by the x86 code are in the BSP renderer, not in the MDL renderer. I don't know if Super8 and MarkV still uses x86 code in their MDL renderers, but it's not really necessary.

Yes, bounding box issues really crashes the MDL renderer. I've had to fix numerous MDL rendering crashes caused by the interpolation code; it must be very carefully implemented, with special care in temporary entities and static entities with framegroups. 

An interesting content bug in the new MD5s is that some of them have bad bounding boxes. That's easily resolvable by recalculating them at load time, but it's still annoying and shouldn't have happened.

All of the d_polyse ASM code actually turned out to be usable, without modification, for both model types. That makes sense because that just consumes trisoup with a position/light/texcoord vertex format.

It's interesting to look at the MD5s in a software renderer without frame interpolation. The 10 fps animations don't look as bad as the old MDLs, probably because the positions aren't compressed down to 8-bit as well. It's still obviously 10 fps, of course, just a subtle improvements.

The MD5s don't support framegroups but they can support skingroups. Anything with framegroups is still a MDL. 

To successfully decompile the progs.dat files from the rerelease? Would be interesting to know what they changed. Especially since there's apparently some code that breaks some vanilla maps. I know at least of one, Pulsar's "The Elder Reality" from Retro Jam 4. 

sCary's shugashack interviewed some nightdive studios people about the re-release

https://www.youtube.com/watch?v=7uWUuqTsnGY 

is somewhat missing. Anyway, nice to see some faces of the guys behind this. 

Yeah that was kind of an odd interview to be honest. It seemed like the guy in the home gym was more interested in making sure they don't get mis-credited, the ceo was obviously just on a by-the-numbers promotional tour and the shacknews guy was waaaay overdoing the "excitable fanboy" schtick, to the point where I wonder if he's overcompensating for never having touched Quake 1 in his life. I'd much rather see an in depth Machine Games interview. 

for consoles, I'll give them that. But for PC, there are better alternatives. Right now they are rather trying to have some stuff exclusive to their port, like that new DOTM campaign, but the community beat them to it, in spite of them not revealing their source code.

In the end, it's OK for people who just want to play Quake and don't want to get too much into tweaking, searching for custom expansions and so on. 

Maybe I am just conditioned by playing AAA console titles like Last of Us and Horizon Zero Dawn; but does anyone else like the motion blur in the new release?

I really like it. Don't miss it too much when playing in other ports but it's a good addition to Quake Ex.

Don't hear this discussed very much.

re: the Nightdive interview. Go back and watch the game capture video. Whoever capped that was NOT familiar with the game and it's hysterical to watch. 

*gets double barrel shotgun*

*shoots ogre from 100 feet away* 

Whoever recorded that gameplay was playing with a gamepad, and don't know how to use strafe to dodge enemy attacks. Also, they tried to get ammo boxes when already having full ammo. At 7:20, they tried several times to jump over the wrong steps on the wall, and eventually gave up. And they keep wasting non-explosive ammo on zombies...

The KEX engine only does the underwater warp horizontally, not vertically. I don't know why they didn't warp it vertically, but it seems that they doubled the amount of horizontal warping to try to compensate.

The lack of view bobbing is disturbing. Turning it off by default was a mistake.

The fog and lighting are very cool, but I'll always miss lightmapped liquids and properly lit item boxes.